cryptogera/zorro
cryptogera/zorro
1
0
Fork 0
Code Issues Pull Requests Projects Releases 2 Wiki Activity

Automated commit

Browse Source
This commit is contained in:
cryptogera 2024-04-04 00:08:59 +00:00
parent 0b47699b90
commit bd0a67fc33
291 changed files with 5343 additions and 8005 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.github/ISSUE_TEMPLATE.md vendored
View File

@ -1,10 +1,10 @@
<!--- Remove sections that do not apply -->
This issue tracker is only for technical issues related to litecoin-core.
This issue tracker is only for technical issues related to zorro-core.
General litecoin questions and/or support requests and are best directed to the [litecointalk.io forums](https://litecointalk.io/).
General zorro questions and/or support requests and are best directed to the [zorrotalk.io forums](https://zorrotalk.io/).
For reporting security issues, please contact the Litecoin developers on the #litecoin-dev Freenode IRC channel or alternatively you can email us at contact@litecoin.org.
For reporting security issues, please contact the Zorro developers on the #zorro-dev Freenode IRC channel or alternatively you can email us at contact@cryptogera.com.
### Describe the issue
@ -23,7 +23,7 @@ Tell us what happens instead
### Screenshots.
If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.
### What version of litecoin-core are you using?
### What version of zorro-core are you using?
List the version number/commit ID, and if it is an official binary, self compiled or a distribution package such as PPA.
### Machine specs:

22
.gitignore vendored
View File

@ -1,13 +1,13 @@
*.tar.gz
*.exe
src/litecoin
src/litecoind
src/litecoin-cli
src/litecoin-tx
src/test/test_litecoin
src/test/test_litecoin_fuzzy
src/qt/test/test_litecoin-qt
src/zorro
src/zorrod
src/zorro-cli
src/zorro-tx
src/test/test_zorro
src/test/test_zorro_fuzzy
src/qt/test/test_zorro-qt
# autoreconf
Makefile.in
@ -74,12 +74,12 @@ src/qt/test/moc*.cpp
# Compilation and Qt preprocessor part
*.qm
Makefile
litecoin-qt
Litecoin-Qt.app
zorro-qt
Zorro-Qt.app
# Unit-tests
Makefile.test
litecoin-qt_test
zorro-qt_test
# Resources cpp
qrc_*.cpp
@ -92,7 +92,7 @@ build
*.gcno
*.gcda
/*.info
test_litecoin.coverage/
test_zorro.coverage/
total.coverage/
coverage_percent.txt

22
.travis.yml
View File

@ -20,20 +20,20 @@ env:
- SDK_URL=https://bitcoincore.org/depends-sources/sdks
- PYTHON_DEBUG=1
- WINEDEBUG=fixme-all
- LITECOIN_SCRYPT=0
- ZORRO_SCRYPT=0
matrix:
# ARM
- HOST=arm-linux-gnueabihf PACKAGES="g++-arm-linux-gnueabihf" DEP_OPTS="NO_QT=1" CHECK_DOC=0 GOAL="install" BITCOIN_CONFIG="--enable-glibc-back-compat --enable-reduce-exports"
# Win32
- HOST=i686-w64-mingw32 DPKG_ADD_ARCH="i386" DEP_OPTS="NO_QT=1" PACKAGES="python3 python3-dev python3-pip nsis g++-mingw-w64-i686 wine1.6 bc" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports" LITECOIN_SCRYPT=1
- HOST=i686-w64-mingw32 DPKG_ADD_ARCH="i386" DEP_OPTS="NO_QT=1" PACKAGES="python3 python3-dev python3-pip nsis g++-mingw-w64-i686 wine1.6 bc" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports" ZORRO_SCRYPT=1
# 32-bit + dash
- HOST=i686-pc-linux-gnu PACKAGES="g++-multilib bc python3-zmq python3-dev python3-pip" DEP_OPTS="NO_QT=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-zmq --enable-glibc-back-compat --enable-reduce-exports LDFLAGS=-static-libstdc++" USE_SHELL="/bin/dash" LITECOIN_SCRYPT=1
- HOST=i686-pc-linux-gnu PACKAGES="g++-multilib bc python3-zmq python3-dev python3-pip" DEP_OPTS="NO_QT=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-zmq --enable-glibc-back-compat --enable-reduce-exports LDFLAGS=-static-libstdc++" USE_SHELL="/bin/dash" ZORRO_SCRYPT=1
# Win64
- HOST=x86_64-w64-mingw32 DPKG_ADD_ARCH="i386" DEP_OPTS="NO_QT=1" PACKAGES="python3 python3-dev python3-pip nsis g++-mingw-w64-x86-64 wine1.6 bc" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports --enable-sse2" LITECOIN_SCRYPT=1
- HOST=x86_64-w64-mingw32 DPKG_ADD_ARCH="i386" DEP_OPTS="NO_QT=1" PACKAGES="python3 python3-dev python3-pip nsis g++-mingw-w64-x86-64 wine1.6 bc" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports --enable-sse2" ZORRO_SCRYPT=1
# x86_64 Linux (uses qt5 dev package instead of depends Qt to speed up build and avoid timeout)
- HOST=x86_64-unknown-linux-gnu PACKAGES="python3-zmq python3-dev python3-pip qtbase5-dev qttools5-dev-tools protobuf-compiler libdbus-1-dev libharfbuzz-dev" DEP_OPTS="NO_QT=1 NO_UPNP=1 DEBUG=1 ALLOW_HOST_PACKAGES=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-zmq --with-gui=qt5 --enable-glibc-back-compat --enable-reduce-exports --enable-sse2 CPPFLAGS=-DDEBUG_LOCKORDER" LITECOIN_SCRYPT=1
- HOST=x86_64-unknown-linux-gnu PACKAGES="python3-zmq python3-dev python3-pip qtbase5-dev qttools5-dev-tools protobuf-compiler libdbus-1-dev libharfbuzz-dev" DEP_OPTS="NO_QT=1 NO_UPNP=1 DEBUG=1 ALLOW_HOST_PACKAGES=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-zmq --with-gui=qt5 --enable-glibc-back-compat --enable-reduce-exports --enable-sse2 CPPFLAGS=-DDEBUG_LOCKORDER" ZORRO_SCRYPT=1
# x86_64 Linux, No wallet
- HOST=x86_64-unknown-linux-gnu PACKAGES="python3 python3-dev python3-pip" DEP_OPTS="NO_WALLET=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-glibc-back-compat --enable-reduce-exports --enable-sse2" LITECOIN_SCRYPT=1
- HOST=x86_64-unknown-linux-gnu PACKAGES="python3 python3-dev python3-pip" DEP_OPTS="NO_WALLET=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-glibc-back-compat --enable-reduce-exports --enable-sse2" ZORRO_SCRYPT=1
# Cross-Mac
- HOST=x86_64-apple-darwin11 PACKAGES="cmake imagemagick libcap-dev librsvg2-bin libz-dev libbz2-dev libtiff-tools python-dev" BITCOIN_CONFIG="--enable-gui --enable-reduce-exports --enable-sse2" OSX_SDK=10.11 GOAL="deploy"
@ -43,7 +43,7 @@ install:
- if [ -n "$DPKG_ADD_ARCH" ]; then sudo dpkg --add-architecture "$DPKG_ADD_ARCH" ; fi
- if [ -n "$PACKAGES" ]; then travis_retry sudo apt-get update; fi
- if [ -n "$PACKAGES" ]; then travis_retry sudo apt-get install --no-install-recommends --no-upgrade -qq $PACKAGES; fi
- if [ "$LITECOIN_SCRYPT" = 1 ]; then travis_retry sudo pip3 install litecoin_scrypt; fi
- if [ "$ZORRO_SCRYPT" = 1 ]; then travis_retry sudo pip3 install zorro_scrypt; fi
before_script:
- if [ "$TRAVIS_EVENT_TYPE" = "pull_request" ]; then contrib/devtools/commit-script-check.sh $TRAVIS_COMMIT_RANGE; fi
- unset CC; unset CXX
@ -53,9 +53,9 @@ before_script:
- if [ -n "$OSX_SDK" -a -f depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz ]; then tar -C depends/SDKs -xf depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz; fi
- make $MAKEJOBS -C depends HOST=$HOST $DEP_OPTS
script:
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "litecoin-project/litecoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then while read LINE; do travis_retry gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys $LINE; done < contrib/verify-commits/trusted-keys; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "litecoin-project/litecoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then git fetch --unshallow; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "litecoin-project/litecoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then contrib/verify-commits/verify-commits.sh; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "zorro-project/zorro" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then while read LINE; do travis_retry gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys $LINE; done < contrib/verify-commits/trusted-keys; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "zorro-project/zorro" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then git fetch --unshallow; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "zorro-project/zorro" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then contrib/verify-commits/verify-commits.sh; fi
- export TRAVIS_COMMIT_LOG=`git log --format=fuller -1`
- if [ -n "$USE_SHELL" ]; then export CONFIG_SHELL="$USE_SHELL"; fi
- OUTDIR=$BASE_OUTDIR/$TRAVIS_PULL_REQUEST/$TRAVIS_JOB_NUMBER-$HOST
@ -65,7 +65,7 @@ script:
- mkdir build && cd build
- ../configure --cache-file=config.cache $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false)
- make distdir VERSION=$HOST
- cd litecoin-$HOST
- cd zorro-$HOST
- ./configure --cache-file=../config.cache $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false)
- make $MAKEJOBS $GOAL || ( echo "Build failure. Verbose build follows." && make $GOAL V=1 ; false )
- export LD_LIBRARY_PATH=$TRAVIS_BUILD_DIR/depends/$HOST/lib

20
CONTRIBUTING.md
View File

@ -1,7 +1,7 @@
Contributing to Litecoin Core
Contributing to Zorro Core
============================
The Litecoin Core project operates an open contributor model where anyone is
The Zorro Core project operates an open contributor model where anyone is
welcome to contribute towards development in the form of peer review, testing
and patches. This document explains the practical process and guidelines for
contributing.
@ -57,12 +57,12 @@ the pull request affects. Valid areas as:
- *Consensus* for changes to consensus critical code
- *Docs* for changes to the documentation
- *Qt* for changes to litecoin-qt
- *Qt* for changes to zorro-qt
- *Mining* for changes to the mining code
- *Net* or *P2P* for changes to the peer-to-peer network code
- *RPC/REST/ZMQ* for changes to the RPC, REST or ZMQ APIs
- *Scripts and tools* for changes to the scripts and tools
- *Tests* for changes to the litecoin unit tests or QA tests
- *Tests* for changes to the zorro unit tests or QA tests
- *Trivial* should **only** be used for PRs that do not change generated
executable code. Notably, refactors (change of function arguments and code
reorganization) and changes in behavior should **not** be marked as trivial.
@ -157,10 +157,10 @@ where possible keep them short, uncomplex and easy to verify.
"Decision Making" Process
-------------------------
The following applies to code changes to the Litecoin Core project, and is not to be confused with overall Litecoin
The following applies to code changes to the Zorro Core project, and is not to be confused with overall Zorro
Network Protocol consensus changes.
Whether a pull request is merged into Litecoin Core rests with the project merge
Whether a pull request is merged into Zorro Core rests with the project merge
maintainers and ultimately the project lead.
Maintainers will take into consideration if a patch is in line with the general
@ -178,7 +178,7 @@ In general, all pull requests must:
- Where bugs are fixed, where possible, there should be unit tests
demonstrating the bug and also proving the fix. This helps prevent regression.
Patches that change Litecoin consensus rules are considerably more involved than
Patches that change Zorro consensus rules are considerably more involved than
normal because they affect the entire ecosystem and so must be preceded by
extensive mailing list discussions and have a numbered BIP. While each case will
be different, one should be prepared to expend more time and effort than for
@ -219,7 +219,7 @@ higher in terms of discussion and peer review requirements, keeping in mind that
mistakes could be very costly to the wider community. This includes refactoring
of consensus critical code.
Where a patch set proposes to change the Litecoin consensus, it must have been
Where a patch set proposes to change the Zorro consensus, it must have been
discussed extensively on the mailing list and IRC, be accompanied by a widely
discussed BIP and have a generally widely perceived technical consensus of being
a worthwhile change based on the judgement of the maintainers.
@ -259,11 +259,11 @@ about:
Release Policy
--------------
The project leader is the release manager for each Litecoin Core release.
The project leader is the release manager for each Zorro Core release.
Copyright
---------
Copyright 2018 The Litecoin Core Developers
Copyright 2018 The Zorro Core Developers
- bitcoin: Copyright (c) 2009-2018 Bitcoin Core Developers (MIT License)

2
COPYING
View File

@ -2,7 +2,7 @@ The MIT License (MIT)
Copyright (c) 2009-2018 The Bitcoin Core developers
Copyright (c) 2009-2018 Bitcoin Developers
Copyright (c) 2011-2018 The Litecoin Core developers
Copyright (c) 2011-2018 The Zorro 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

4
INSTALL.md
View File

@ -1,5 +1,5 @@
Building Litecoin
Building Zorro
================
See doc/build-*.md for instructions on building the various
elements of the Litecoin Core reference implementation of Litecoin.
elements of the Zorro Core reference implementation of Zorro.

10
Makefile.am
View File

@ -25,7 +25,7 @@ BITCOIN_WIN_INSTALLER=$(PACKAGE)-$(PACKAGE_VERSION)-win$(WINDOWS_BITS)-setup$(EX
empty :=
space := $(empty) $(empty)
OSX_APP=Litecoin-Qt.app
OSX_APP=Zorro-Qt.app
OSX_VOLNAME = $(subst $(space),-,$(PACKAGE_NAME))
OSX_DMG = $(OSX_VOLNAME).dmg
OSX_BACKGROUND_SVG=background.svg
@ -95,7 +95,7 @@ $(OSX_APP)/Contents/Resources/bitcoin.icns: $(OSX_INSTALLER_ICONS)
$(MKDIR_P) $(@D)
$(INSTALL_DATA) $< $@
$(OSX_APP)/Contents/MacOS/Litecoin-Qt: $(BITCOIN_QT_BIN)
$(OSX_APP)/Contents/MacOS/Zorro-Qt: $(BITCOIN_QT_BIN)
$(MKDIR_P) $(@D)
STRIPPROG="$(STRIP)" $(INSTALL_STRIP_PROGRAM) $< $@
@ -105,7 +105,7 @@ $(OSX_APP)/Contents/Resources/Base.lproj/InfoPlist.strings:
OSX_APP_BUILT=$(OSX_APP)/Contents/PkgInfo $(OSX_APP)/Contents/Resources/empty.lproj \
$(OSX_APP)/Contents/Resources/bitcoin.icns $(OSX_APP)/Contents/Info.plist \
$(OSX_APP)/Contents/MacOS/Litecoin-Qt $(OSX_APP)/Contents/Resources/Base.lproj/InfoPlist.strings
$(OSX_APP)/Contents/MacOS/Zorro-Qt $(OSX_APP)/Contents/Resources/Base.lproj/InfoPlist.strings
osx_volname:
echo $(OSX_VOLNAME) >$@
@ -130,7 +130,7 @@ $(APP_DIST_DIR)/Applications:
@rm -f $@
@cd $(@D); $(LN_S) /Applications $(@F)
$(APP_DIST_EXTRAS): $(APP_DIST_DIR)/$(OSX_APP)/Contents/MacOS/Litecoin-Qt
$(APP_DIST_EXTRAS): $(APP_DIST_DIR)/$(OSX_APP)/Contents/MacOS/Zorro-Qt
$(OSX_DMG): $(APP_DIST_EXTRAS)
$(GENISOIMAGE) -no-cache-inodes -D -l -probe -V "$(OSX_VOLNAME)" -no-pad -r -dir-mode 0755 -apple -o $@ dist
@ -145,7 +145,7 @@ $(APP_DIST_DIR)/.background/$(OSX_BACKGROUND_IMAGE): $(OSX_BACKGROUND_IMAGE_DPIF
$(APP_DIST_DIR)/.DS_Store: $(OSX_DSSTORE_GEN)
$(PYTHON) $< "$@" "$(OSX_VOLNAME)"
$(APP_DIST_DIR)/$(OSX_APP)/Contents/MacOS/Litecoin-Qt: $(OSX_APP_BUILT) $(OSX_PACKAGING)
$(APP_DIST_DIR)/$(OSX_APP)/Contents/MacOS/Zorro-Qt: $(OSX_APP_BUILT) $(OSX_PACKAGING)
INSTALLNAMETOOL=$(INSTALLNAMETOOL) OTOOL=$(OTOOL) STRIP=$(STRIP) $(PYTHON) $(OSX_DEPLOY_SCRIPT) $(OSX_APP) -translations-dir=$(QT_TRANSLATION_DIR) -add-qt-tr $(OSX_QT_TRANSLATIONS) -verbose 2
deploydir: $(APP_DIST_EXTRAS)

87
README.md
View File

@ -1,79 +1,30 @@
Litecoin Core integration/staging tree
=====================================
[![Build Status](https://travis-ci.org/litecoin-project/litecoin.svg?branch=master)](https://travis-ci.org/litecoin-project/litecoin)
Zorro Core
==============
https://litecoin.org
https://cryptogera.com
What is Litecoin?
What is Zorro?
------------------
Born on April 03, 2024 at 00:18:45 GMT, Zorro is an experimental digital currency of the Bitcoin family, which enables instant payments to anyone, anywhere in the world. It uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Zorro Core is the name of open source software which enables the use of this currency.
Zorro has a maximum circulating supply of 84,000,000 ZRR, which is four times larger than Bitcoin's maximum circulating supply of 21,000,000 BTC. It uses the Scrypt algorithm, just like the already popular Bitcoin family members: Litecoin and Dogecoin, thus making it compatible with the already existing cyptocurrency platform (developer code, mining software, mining pools, wallets, trading platforms) and mining hardware (CPU, GPU, ASIC).
For more information, as well as an immediately useable, binary version of the Zorro Core software, see [https://git.cryptogera.com/cryptogera/zorro/releases](https://git.cryptogera.com/cryptogera/zorro/releases).
TCP Ports
----------------
Litecoin is an experimental digital currency that enables instant payments to
anyone, anywhere in the world. Litecoin uses peer-to-peer technology to operate
with no central authority: managing transactions and issuing money are carried
out collectively by the network. Litecoin Core is the name of open source
software which enables the use of this currency.
Zorro Core by default uses port `18641` for peer-to-peer communication that is needed to synchronize the "mainnet" blockchain and stay informed of new transactions and blocks. Additionally, a JSONRPC port can be opened, which defaults to port `18642` for mainnet nodes. It is strongly recommended to not expose RPC ports to the public internet.
For more information, as well as an immediately useable, binary version of
the Litecoin Core software, see [https://litecoin.org](https://litecoin.org).
| Function | mainnet | testnet | regtest |
| :------- | ------: | ------: | ------: |
| P2P | 18641 | 19062 | 16106 |
| RPC | 18642 | 19063 | 16107 |
License
-------
Litecoin Core is released under the terms of the MIT license. See [COPYING](COPYING) for more
information or see https://opensource.org/licenses/MIT.
Zorro Core is released under the terms of the MIT license. See [COPYING](COPYING) for more information or see https://opensource.org/licenses/MIT.
Development Process
-------------------
The `master` branch is regularly built and tested, but is not guaranteed to be
completely stable. [Tags](https://github.com/litecoin-project/litecoin/tags) are created
regularly to indicate new official, stable release versions of Litecoin Core.
The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md).
The developer [mailing list](https://groups.google.com/forum/#!forum/litecoin-dev)
should be used to discuss complicated or controversial changes before working
on a patch set.
Developer IRC can be found on Freenode at #litecoin-dev.
Testing
-------
Testing and code review is the bottleneck for development; we get more pull
requests than we can review and test on short notice. Please be patient and help out by testing
other people's pull requests, and remember this is a security-critical project where any mistake might cost people
lots of money.
### Automated Testing
Developers are strongly encouraged to write [unit tests](src/test/README.md) for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled in configure) with: `make check`. Further details on running
and extending unit tests can be found in [/src/test/README.md](/src/test/README.md).
There are also [regression and integration tests](/test), written
in Python, that are run automatically on the build server.
These tests can be run (if the [test dependencies](/test) are installed) with: `test/functional/test_runner.py`
The Travis CI system makes sure that every pull request is built for Windows, Linux, and OS X, and that unit/sanity tests are run automatically.
### Manual Quality Assurance (QA) Testing
Changes should be tested by somebody other than the developer who wrote the
code. This is especially important for large or high-risk changes. It is useful
to add a test plan to the pull request description if testing the changes is
not straightforward.
Translations
------------
We only accept translation fixes that are submitted through [Bitcoin Core's Transifex page](https://www.transifex.com/projects/p/bitcoin/).
Translations are converted to Litecoin periodically.
Translations are periodically pulled from Transifex and merged into the git repository. See the
[translation process](doc/translation_process.md) for details on how this works.
**Important**: We do not accept translation changes as GitHub pull requests because the next
pull from Transifex would automatically overwrite them again.

4
build-aux/m4/bitcoin_qt.m4
View File

@ -7,7 +7,7 @@ dnl Output: If qt version is auto, set bitcoin_enable_qt to false. Else, exit.
AC_DEFUN([BITCOIN_QT_FAIL],[
if test "x$bitcoin_qt_want_version" = "xauto" && test x$bitcoin_qt_force != xyes; then
if test x$bitcoin_enable_qt != xno; then
AC_MSG_WARN([$1; litecoin-qt frontend will not be built])
AC_MSG_WARN([$1; zorro-qt frontend will not be built])
fi
bitcoin_enable_qt=no
bitcoin_enable_qt_test=no
@ -54,7 +54,7 @@ AC_DEFUN([BITCOIN_QT_INIT],[
dnl enable qt support
AC_ARG_WITH([gui],
[AS_HELP_STRING([--with-gui@<:@=no|qt4|qt5|auto@:>@],
[build litecoin-qt GUI (default=auto, qt5 tried first)])],
[build zorro-qt GUI (default=auto, qt5 tried first)])],
[
bitcoin_qt_want_version=$withval
if test x$bitcoin_qt_want_version = xyes; then

30
configure.ac
View File

@ -7,17 +7,17 @@ define(_CLIENT_VERSION_BUILD, 0)
define(_CLIENT_VERSION_IS_RELEASE, true)
define(_COPYRIGHT_YEAR, 2018)
define(_COPYRIGHT_HOLDERS,[The %s developers])
define(_COPYRIGHT_HOLDERS_SUBSTITUTION,[[Litecoin Core]])
AC_INIT([Litecoin Core],[_CLIENT_VERSION_MAJOR._CLIENT_VERSION_MINOR._CLIENT_VERSION_REVISION],[https://github.com/litecoin-project/litecoin/issues],[litecoin],[https://litecoin.org/])
define(_COPYRIGHT_HOLDERS_SUBSTITUTION,[[Zorro Core]])
AC_INIT([Zorro Core],[_CLIENT_VERSION_MAJOR._CLIENT_VERSION_MINOR._CLIENT_VERSION_REVISION],[https://git.cryptogera.com/cryptogera/zorro/issues],[zorro],[https://cryptogera.com/])
AC_CONFIG_SRCDIR([src/validation.cpp])
AC_CONFIG_HEADERS([src/config/bitcoin-config.h])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([build-aux/m4])
BITCOIN_DAEMON_NAME=litecoind
BITCOIN_GUI_NAME=litecoin-qt
BITCOIN_CLI_NAME=litecoin-cli
BITCOIN_TX_NAME=litecoin-tx
BITCOIN_DAEMON_NAME=zorrod
BITCOIN_GUI_NAME=zorro-qt
BITCOIN_CLI_NAME=zorro-cli
BITCOIN_TX_NAME=zorro-tx
dnl Unless the user specified ARFLAGS, force it to be cr
AC_ARG_VAR(ARFLAGS, [Flags for the archiver, defaults to <cr> if not set])
@ -297,7 +297,7 @@ CPPFLAGS="$CPPFLAGS -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS"
AC_ARG_WITH([utils],
[AS_HELP_STRING([--with-utils],
[build litecoin-cli litecoin-tx (default=yes)])],
[build zorro-cli zorro-tx (default=yes)])],
[build_bitcoin_utils=$withval],
[build_bitcoin_utils=yes])
@ -309,7 +309,7 @@ AC_ARG_WITH([libs],
AC_ARG_WITH([daemon],
[AS_HELP_STRING([--with-daemon],
[build litecoind daemon (default=yes)])],
[build zorrod daemon (default=yes)])],
[build_bitcoind=$withval],
[build_bitcoind=yes])
@ -1036,11 +1036,11 @@ AC_SUBST(UNIVALUE_LIBS)
BITCOIN_QT_PATH_PROGS([PROTOC], [protoc],$protoc_bin_path)
AC_MSG_CHECKING([whether to build litecoind])
AC_MSG_CHECKING([whether to build zorrod])
AM_CONDITIONAL([BUILD_BITCOIND], [test x$build_bitcoind = xyes])
AC_MSG_RESULT($build_bitcoind)
AC_MSG_CHECKING([whether to build utils (litecoin-cli litecoin-tx)])
AC_MSG_CHECKING([whether to build utils (zorro-cli zorro-tx)])
AM_CONDITIONAL([BUILD_BITCOIN_UTILS], [test x$build_bitcoin_utils = xyes])
AC_MSG_RESULT($build_bitcoin_utils)
@ -1141,7 +1141,7 @@ if test x$bitcoin_enable_qt != xno; then
AC_MSG_WARN("xgettext is required to update qt translations")
fi
AC_MSG_CHECKING([whether to build test_litecoin-qt])
AC_MSG_CHECKING([whether to build test_zorro-qt])
if test x$use_gui_tests$bitcoin_enable_qt_test = xyesyes; then
AC_MSG_RESULT([yes])
BUILD_TEST_QT="yes"
@ -1152,7 +1152,7 @@ fi
AM_CONDITIONAL([ENABLE_ZMQ], [test "x$use_zmq" = "xyes"])
AC_MSG_CHECKING([whether to build test_litecoin])
AC_MSG_CHECKING([whether to build test_zorro])
if test x$use_tests = xyes; then
AC_MSG_RESULT([yes])
BUILD_TEST="yes"
@ -1198,9 +1198,9 @@ AM_CONDITIONAL([HARDEN],[test x$use_hardening = xyes])
AM_CONDITIONAL([ENABLE_HWCRC32],[test x$enable_hwcrc32 = xyes])
AM_CONDITIONAL([EXPERIMENTAL_ASM],[test x$experimental_asm = xyes])
AC_DEFINE(CLIENT_VERSION_MAJOR, _CLIENT_VERSION_MAJOR, [Major version])
AC_DEFINE(CLIENT_VERSION_MINOR, _CLIENT_VERSION_MINOR, [Minor version])
AC_DEFINE(CLIENT_VERSION_REVISION, _CLIENT_VERSION_REVISION, [Build revision])
AC_DEFINE(CLIENT_VERSION_MAJOR, _CLIENT_VERSION_MAJOR, 0)
AC_DEFINE(CLIENT_VERSION_MINOR, _CLIENT_VERSION_MINOR, 15)
AC_DEFINE(CLIENT_VERSION_REVISION, _CLIENT_VERSION_REVISION, 1)
AC_DEFINE(CLIENT_VERSION_BUILD, _CLIENT_VERSION_BUILD, [Version Build])
AC_DEFINE(CLIENT_VERSION_IS_RELEASE, _CLIENT_VERSION_IS_RELEASE, [Version is release])
AC_DEFINE(COPYRIGHT_YEAR, _COPYRIGHT_YEAR, [Copyright year])

14
contrib/README.md
View File

@ -13,7 +13,7 @@ Construct a linear, no-fork, best version of the blockchain.
### [Qos](/contrib/qos) ###
A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Litecoin network. This means one can have an always-on litecoind instance running, and another local litecoind/litecoin-qt instance which connects to this node and receives blocks from it.
A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Zorro network. This means one can have an always-on zorrod instance running, and another local zorrod/zorro-qt instance which connects to this node and receives blocks from it.
### [Seeds](/contrib/seeds) ###
Utility to generate the pnSeed[] array that is compiled into the client.
@ -22,20 +22,20 @@ Build Tools and Keys
---------------------
### [Debian](/contrib/debian) ###
Contains files used to package litecoind/litecoin-qt
for Debian-based Linux systems. If you compile litecoind/litecoin-qt yourself, there are some useful files here.
Contains files used to package zorrod/zorro-qt
for Debian-based Linux systems. If you compile zorrod/zorro-qt yourself, there are some useful files here.
### [Gitian-descriptors](/contrib/gitian-descriptors) ###
Notes on getting Gitian builds up and running using KVM.
### [Gitian-keys](/contrib/gitian-keys)
PGP keys used for signing Litecoin Core [Gitian release](/doc/release-process.md) results.
PGP keys used for signing Zorro Core [Gitian release](/doc/release-process.md) results.
### [MacDeploy](/contrib/macdeploy) ###
Scripts and notes for Mac builds.
### [RPM](/contrib/rpm) ###
RPM spec file for building litecoin-core on RPM based distributions
RPM spec file for building zorro-core on RPM based distributions
### [Gitian-build](/contrib/gitian-build.sh) ###
Script for running full Gitian builds.
@ -44,7 +44,7 @@ Test and Verify Tools
---------------------
### [TestGen](/contrib/testgen) ###
Utilities to generate test vectors for the data-driven Litecoin tests.
Utilities to generate test vectors for the data-driven Zorro tests.
### [Verify Binaries](/contrib/verifybinaries) ###
This script attempts to download and verify the signature file SHA256SUMS.asc from litecoin.org.
This script attempts to download and verify the signature file SHA256SUMS.asc from cryptogera.com.

6
contrib/debian/examples/bitcoin.conf
View File

@ -44,11 +44,11 @@
# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:9333
#addnode=10.0.0.2:18641
# Alternatively use as many connect= settings as you like to connect ONLY to specific peers
#connect=69.164.218.197
#connect=10.0.0.1:9333
#connect=10.0.0.1:18641
# Listening mode, enabled by default except when 'connect' is being used
#listen=1
@ -110,7 +110,7 @@
#rpcallowip=2001:db8:85a3:0:0:8a2e:370:7334/96
# Listen for RPC connections on this TCP port:
#rpcport=9332
#rpcport=18642
# You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
# running on another host using this option:

20
contrib/devtools/gen-manpages.sh
View File

@ -4,26 +4,26 @@ TOPDIR=${TOPDIR:-$(git rev-parse --show-toplevel)}
SRCDIR=${SRCDIR:-$TOPDIR/src}
MANDIR=${MANDIR:-$TOPDIR/doc/man}
LITECOIND=${LITECOIND:-$SRCDIR/litecoind}
LITECOINCLI=${LITECOINCLI:-$SRCDIR/litecoin-cli}
LITECOINTX=${LITECOINTX:-$SRCDIR/litecoin-tx}
LITECOINQT=${LITECOINQT:-$SRCDIR/qt/litecoin-qt}
ZORROD=${ZORROD:-$SRCDIR/zorrod}
ZORROCLI=${ZORROCLI:-$SRCDIR/zorro-cli}
ZORROTX=${ZORROTX:-$SRCDIR/zorro-tx}
ZORROQT=${ZORROQT:-$SRCDIR/qt/zorro-qt}
[ ! -x $LITECOIND ] && echo "$LITECOIND not found or not executable." && exit 1
[ ! -x $ZORROD ] && echo "$ZORROD not found or not executable." && exit 1
# The autodetected version git tag can screw up manpage output a little bit
LTCVER=($($LITECOINCLI --version | head -n1 | awk -F'[ -]' '{ print $6, $7 }'))
ZRRVER=($($ZORROCLI --version | head -n1 | awk -F'[ -]' '{ print $6, $7 }'))
# Create a footer file with copyright content.
# This gets autodetected fine for bitcoind if --version-string is not set,
# but has different outcomes for bitcoin-qt and bitcoin-cli.
echo "[COPYRIGHT]" > footer.h2m
$LITECOIND --version | sed -n '1!p' >> footer.h2m
$ZORROD --version | sed -n '1!p' >> footer.h2m
for cmd in $LITECOIND $LITECOINCLI $LITECOINTX $LITECOINQT; do
for cmd in $ZORROD $ZORROCLI $ZORROTX $ZORROQT; do
cmdname="${cmd##*/}"
help2man -N --version-string=${LTCVER[0]} --include=footer.h2m -o ${MANDIR}/${cmdname}.1 ${cmd}
sed -i "s/\\\-${LTCVER[1]}//g" ${MANDIR}/${cmdname}.1
help2man -N --version-string=${ZRRVER[0]} --include=footer.h2m -o ${MANDIR}/${cmdname}.1 ${cmd}
sed -i "s/\\\-${ZRRVER[1]}//g" ${MANDIR}/${cmdname}.1
done
rm -f footer.h2m

62
contrib/gitian-build.sh
View File

@ -17,7 +17,7 @@ osx=true
SIGNER=
VERSION=
commit=false
url=https://github.com/litecoin-project/litecoin
url=https://git.cryptogera.com/cryptogera/zorro
proc=2
mem=2000
lxc=true
@ -31,7 +31,7 @@ commitFiles=true
read -d '' usage <<- EOF
Usage: $scriptName [-c|u|v|b|s|B|o|h|j|m|] signer version
Run this script from the directory containing the litecoin, gitian-builder, gitian.sigs.ltc, and litecoin-detached-sigs.
Run this script from the directory containing the zorro, gitian-builder, gitian.sigs.ltc, and zorro-detached-sigs.
Arguments:
signer GPG signer to sign each build assert file
@ -39,7 +39,7 @@ version Version number, commit, or branch to build. If building a commit or bra
Options:
-c|--commit Indicate that the version argument is for a commit or branch
-u|--url Specify the URL of the repository. Default is https://github.com/litecoin-project/litecoin
-u|--url Specify the URL of the repository. Default is https://git.cryptogera.com/cryptogera/zorro
-v|--verify Verify the gitian build
-b|--build Do a gitian build
-s|--sign Make signed binaries for Windows and Mac OSX
@ -232,8 +232,8 @@ echo ${COMMIT}
if [[ $setup = true ]]
then
sudo apt-get install ruby apache2 git apt-cacher-ng python-vm-builder qemu-kvm qemu-utils
git clone https://github.com/litecoin-project/gitian.sigs.ltc.git
git clone https://github.com/litecoin-project/litecoin-detached-sigs.git
git clone https://github.com/zorro-project/gitian.sigs.ltc.git
git clone https://git.cryptogera.com/cryptogera/zorro-detached-sigs.git
git clone https://github.com/devrandom/gitian-builder.git
pushd ./gitian-builder
if [[ -n "$USE_LXC" ]]
@ -247,7 +247,7 @@ then
fi
# Set up build
pushd ./litecoin
pushd ./zorro
git fetch
git checkout ${COMMIT}
popd
@ -256,7 +256,7 @@ popd
if [[ $build = true ]]
then
# Make output folder
mkdir -p ./litecoin-binaries/${VERSION}
mkdir -p ./zorro-binaries/${VERSION}
# Build Dependencies
echo ""
@ -266,7 +266,7 @@ then
mkdir -p inputs
wget -N -P inputs $osslPatchUrl
wget -N -P inputs $osslTarUrl
make -C ../litecoin/depends download SOURCES_PATH=`pwd`/cache/common
make -C ../zorro/depends download SOURCES_PATH=`pwd`/cache/common
# Linux
if [[ $linux = true ]]
@ -274,9 +274,9 @@ then
echo ""
echo "Compiling ${VERSION} Linux"
echo ""
./bin/gbuild -j ${proc} -m ${mem} --commit litecoin=${COMMIT} --url litecoin=${url} ../litecoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-linux.yml
mv build/out/litecoin-*.tar.gz build/out/src/litecoin-*.tar.gz ../litecoin-binaries/${VERSION}
./bin/gbuild -j ${proc} -m ${mem} --commit zorro=${COMMIT} --url zorro=${url} ../zorro/contrib/gitian-descriptors/gitian-linux.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-linux.yml
mv build/out/zorro-*.tar.gz build/out/src/zorro-*.tar.gz ../zorro-binaries/${VERSION}
fi
# Windows
if [[ $windows = true ]]
@ -284,10 +284,10 @@ then
echo ""
echo "Compiling ${VERSION} Windows"
echo ""
./bin/gbuild -j ${proc} -m ${mem} --commit litecoin=${COMMIT} --url litecoin=${url} ../litecoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-win.yml
mv build/out/litecoin-*-win-unsigned.tar.gz inputs/litecoin-win-unsigned.tar.gz
mv build/out/litecoin-*.zip build/out/litecoin-*.exe ../litecoin-binaries/${VERSION}
./bin/gbuild -j ${proc} -m ${mem} --commit zorro=${COMMIT} --url zorro=${url} ../zorro/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-win.yml
mv build/out/zorro-*-win-unsigned.tar.gz inputs/zorro-win-unsigned.tar.gz
mv build/out/zorro-*.zip build/out/zorro-*.exe ../zorro-binaries/${VERSION}
fi
# Mac OSX
if [[ $osx = true ]]
@ -295,10 +295,10 @@ then
echo ""
echo "Compiling ${VERSION} Mac OSX"
echo ""
./bin/gbuild -j ${proc} -m ${mem} --commit litecoin=${COMMIT} --url litecoin=${url} ../litecoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-osx.yml
mv build/out/litecoin-*-osx-unsigned.tar.gz inputs/litecoin-osx-unsigned.tar.gz
mv build/out/litecoin-*.tar.gz build/out/litecoin-*.dmg ../litecoin-binaries/${VERSION}
./bin/gbuild -j ${proc} -m ${mem} --commit zorro=${COMMIT} --url zorro=${url} ../zorro/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-osx.yml
mv build/out/zorro-*-osx-unsigned.tar.gz inputs/zorro-osx-unsigned.tar.gz
mv build/out/zorro-*.tar.gz build/out/zorro-*.dmg ../zorro-binaries/${VERSION}
fi
popd
@ -325,27 +325,27 @@ then
echo ""
echo "Verifying v${VERSION} Linux"
echo ""
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-linux ../litecoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-linux ../zorro/contrib/gitian-descriptors/gitian-linux.yml
# Windows
echo ""
echo "Verifying v${VERSION} Windows"
echo ""
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-win-unsigned ../litecoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-win-unsigned ../zorro/contrib/gitian-descriptors/gitian-win.yml
# Mac OSX
echo ""
echo "Verifying v${VERSION} Mac OSX"
echo ""
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-unsigned ../litecoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-unsigned ../zorro/contrib/gitian-descriptors/gitian-osx.yml
# Signed Windows
echo ""
echo "Verifying v${VERSION} Signed Windows"
echo ""
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-signed ../litecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-signed ../zorro/contrib/gitian-descriptors/gitian-osx-signer.yml
# Signed Mac OSX
echo ""
echo "Verifying v${VERSION} Signed Mac OSX"
echo ""
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-signed ../litecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-signed ../zorro/contrib/gitian-descriptors/gitian-osx-signer.yml
popd
fi
@ -360,10 +360,10 @@ then
echo ""
echo "Signing ${VERSION} Windows"
echo ""
./bin/gbuild -i --commit signature=${COMMIT} ../litecoin/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-win-signed --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-win-signer.yml
mv build/out/litecoin-*win64-setup.exe ../litecoin-binaries/${VERSION}
mv build/out/litecoin-*win32-setup.exe ../litecoin-binaries/${VERSION}
./bin/gbuild -i --commit signature=${COMMIT} ../zorro/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-win-signed --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-win-signer.yml
mv build/out/zorro-*win64-setup.exe ../zorro-binaries/${VERSION}
mv build/out/zorro-*win32-setup.exe ../zorro-binaries/${VERSION}
fi
# Sign Mac OSX
if [[ $osx = true ]]
@ -371,9 +371,9 @@ then
echo ""
echo "Signing ${VERSION} Mac OSX"
echo ""
./bin/gbuild -i --commit signature=${COMMIT} ../litecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-osx-signed --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
mv build/out/litecoin-osx-signed.dmg ../litecoin-binaries/${VERSION}/litecoin-${VERSION}-osx.dmg
./bin/gbuild -i --commit signature=${COMMIT} ../zorro/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gsign -p $signProg --signer $SIGNER --release ${VERSION}-osx-signed --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-osx-signer.yml
mv build/out/zorro-osx-signed.dmg ../zorro-binaries/${VERSION}/zorro-${VERSION}-osx.dmg
fi
popd

4
contrib/gitian-descriptors/README.md
View File

@ -19,7 +19,7 @@ Sanity checks:
Once you've got the right hardware and software:
git clone git://github.com/litecoin-project/litecoin.git
git clone git://git.cryptogera.com/cryptogera/zorro.git
git clone git://github.com/devrandom/gitian-builder.git
mkdir gitian-builder/inputs
cd gitian-builder/inputs
@ -61,5 +61,5 @@ Here's a description of Gavin's setup on OSX 10.6:
5. Still inside Ubuntu, tell gitian-builder to use LXC, then follow the "Once you've got the right hardware and software" instructions above:
export USE_LXC=1
git clone git://github.com/litecoin-project/litecoin.git
git clone git://git.cryptogera.com/cryptogera/zorro.git
... etc

18
contrib/gitian-descriptors/gitian-linux.yml
View File

@ -1,5 +1,5 @@
---
name: "litecoin-linux-0.15"
name: "zorro-linux-0.15"
enable_cache: true
suites:
- "trusty"
@ -28,8 +28,8 @@ packages:
- "ca-certificates"
- "python"
remotes:
- "url": "https://github.com/litecoin-project/litecoin.git"
"dir": "litecoin"
- "url": "https://git.cryptogera.com/cryptogera/zorro.git"
"dir": "zorro"
files: []
script: |
@ -113,7 +113,7 @@ script: |
chmod +x ${WRAP_DIR}/${prog}
done
cd litecoin
cd zorro
BASEPREFIX=`pwd`/depends
# Build dependencies for each host
for i in $HOSTS; do
@ -135,13 +135,13 @@ script: |
./autogen.sh
CONFIG_SITE=${BASEPREFIX}/`echo "${HOSTS}" | awk '{print $1;}'`/share/config.site ./configure --prefix=/
make dist
SOURCEDIST=`echo litecoin-*.tar.gz`
SOURCEDIST=`echo zorro-*.tar.gz`
DISTNAME=`echo ${SOURCEDIST} | sed 's/.tar.*//'`
# Correct tar file order
mkdir -p temp
pushd temp
tar xf ../$SOURCEDIST
find litecoin-* | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ../$SOURCEDIST
find zorro-* | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ../$SOURCEDIST
popd
# Workaround for tarball not building with the bare tag version (prep)
@ -182,13 +182,13 @@ script: |
find . -name "lib*.a" -delete
rm -rf ${DISTNAME}/lib/pkgconfig
# Litecoin: Delete libbitcoin from binary distribution for now, see #192
# Zorro: Delete libbitcoin from binary distribution for now, see #192
rm -rf ${DISTNAME}/lib/
rm -rf ${DISTNAME}/include/
# Litecoin: ends
# Zorro: ends
find ${DISTNAME}/bin -type f -executable -exec ../contrib/devtools/split-debug.sh {} {} {}.dbg \;
#find ${DISTNAME}/lib -type f -exec ../contrib/devtools/split-debug.sh {} {} {}.dbg \; # Litecoin: see issue 192
#find ${DISTNAME}/lib -type f -exec ../contrib/devtools/split-debug.sh {} {} {}.dbg \; # Zorro: see issue 192
find ${DISTNAME} -not -name "*.dbg" | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ${OUTDIR}/${DISTNAME}-${i}.tar.gz
find ${DISTNAME} -name "*.dbg" | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ${OUTDIR}/${DISTNAME}-${i}-debug.tar.gz
cd ../../

10
contrib/gitian-descriptors/gitian-osx-signer.yml
View File

@ -1,5 +1,5 @@
---
name: "litecoin-dmg-signer"
name: "zorro-dmg-signer"
suites:
- "trusty"
architectures:
@ -7,10 +7,10 @@ architectures:
packages:
- "faketime"
remotes:
- "url": "https://github.com/litecoin-project/litecoin-detached-sigs.git"
- "url": "https://git.cryptogera.com/cryptogera/zorro-detached-sigs.git"
"dir": "signature"
files:
- "litecoin-osx-unsigned.tar.gz"
- "zorro-osx-unsigned.tar.gz"
script: |
WRAP_DIR=$HOME/wrapped
mkdir -p ${WRAP_DIR}
@ -27,8 +27,8 @@ script: |
chmod +x ${WRAP_DIR}/${prog}
done
UNSIGNED=litecoin-osx-unsigned.tar.gz
SIGNED=litecoin-osx-signed.dmg
UNSIGNED=zorro-osx-unsigned.tar.gz
SIGNED=zorro-osx-signed.dmg
tar -xf ${UNSIGNED}
OSX_VOLNAME="$(cat osx_volname)"

12
contrib/gitian-descriptors/gitian-osx.yml
View File

@ -1,5 +1,5 @@
---
name: "litecoin-osx-0.15"
name: "zorro-osx-0.15"
enable_cache: true
suites:
- "trusty"
@ -28,8 +28,8 @@ packages:
- "python-setuptools"
- "fonts-tuffy"
remotes:
- "url": "https://github.com/litecoin-project/litecoin.git"
"dir": "litecoin"
- "url": "https://git.cryptogera.com/cryptogera/zorro.git"
"dir": "zorro"
files:
- "MacOSX10.11.sdk.tar.gz"
script: |
@ -83,7 +83,7 @@ script: |
create_per-host_faketime_wrappers "2000-01-01 12:00:00"
export PATH=${WRAP_DIR}:${PATH}
cd litecoin
cd zorro
BASEPREFIX=`pwd`/depends
mkdir -p ${BASEPREFIX}/SDKs
@ -104,14 +104,14 @@ script: |
./autogen.sh
CONFIG_SITE=${BASEPREFIX}/`echo "${HOSTS}" | awk '{print $1;}'`/share/config.site ./configure --prefix=/
make dist
SOURCEDIST=`echo litecoin-*.tar.gz`
SOURCEDIST=`echo zorro-*.tar.gz`
DISTNAME=`echo ${SOURCEDIST} | sed 's/.tar.*//'`
# Correct tar file order
mkdir -p temp
pushd temp
tar xf ../$SOURCEDIST
find litecoin-* | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ../$SOURCEDIST
find zorro-* | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ../$SOURCEDIST
popd
# Workaround for tarball not building with the bare tag version (prep)

8
contrib/gitian-descriptors/gitian-win-signer.yml
View File

@ -1,5 +1,5 @@
---
name: "litecoin-win-signer"
name: "zorro-win-signer"
suites:
- "trusty"
architectures:
@ -8,12 +8,12 @@ packages:
- "libssl-dev"
- "autoconf"
remotes:
- "url": "https://github.com/litecoin-project/litecoin-detached-sigs.git"
- "url": "https://git.cryptogera.com/cryptogera/zorro-detached-sigs.git"
"dir": "signature"
files:
- "osslsigncode-1.7.1.tar.gz"
- "osslsigncode-Backports-to-1.7.1.patch"
- "litecoin-win-unsigned.tar.gz"
- "zorro-win-unsigned.tar.gz"
script: |
BUILD_DIR=`pwd`
SIGDIR=${BUILD_DIR}/signature/win
@ -23,7 +23,7 @@ script: |
echo "a8c4e9cafba922f89de0df1f2152e7be286aba73f78505169bc351a7938dd911 osslsigncode-Backports-to-1.7.1.patch" | sha256sum -c
mkdir -p ${UNSIGNED_DIR}
tar -C ${UNSIGNED_DIR} -xf litecoin-win-unsigned.tar.gz
tar -C ${UNSIGNED_DIR} -xf zorro-win-unsigned.tar.gz
tar xf osslsigncode-1.7.1.tar.gz
cd osslsigncode-1.7.1

16
contrib/gitian-descriptors/gitian-win.yml
View File

@ -1,5 +1,5 @@
---
name: "litecoin-win-0.15"
name: "zorro-win-0.15"
enable_cache: true
suites:
- "trusty"
@ -22,8 +22,8 @@ packages:
- "ca-certificates"
- "python"
remotes:
- "url": "https://github.com/litecoin-project/litecoin.git"
"dir": "litecoin"
- "url": "https://git.cryptogera.com/cryptogera/zorro.git"
"dir": "zorro"
files: []
script: |
WRAP_DIR=$HOME/wrapped
@ -101,7 +101,7 @@ script: |
create_per-host_linker_wrapper "2000-01-01 12:00:00"
export PATH=${WRAP_DIR}:${PATH}
cd litecoin
cd zorro
BASEPREFIX=`pwd`/depends
# Build dependencies for each host
for i in $HOSTS; do
@ -119,14 +119,14 @@ script: |
./autogen.sh
CONFIG_SITE=${BASEPREFIX}/`echo "${HOSTS}" | awk '{print $1;}'`/share/config.site ./configure --prefix=/
make dist
SOURCEDIST=`echo litecoin-*.tar.gz`
SOURCEDIST=`echo zorro-*.tar.gz`
DISTNAME=`echo ${SOURCEDIST} | sed 's/.tar.*//'`
# Correct tar file order
mkdir -p temp
pushd temp
tar xf ../$SOURCEDIST
find litecoin-* | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ../$SOURCEDIST
find zorro-* | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ../$SOURCEDIST
mkdir -p $OUTDIR/src
cp ../$SOURCEDIST $OUTDIR/src
popd
@ -155,7 +155,7 @@ script: |
make deploy
make install DESTDIR=${INSTALLPATH}
rename 's/-setup\.exe$/-setup-unsigned.exe/' *-setup.exe
cp -f litecoin-*setup*.exe $OUTDIR/
cp -f zorro-*setup*.exe $OUTDIR/
cd installed
mv ${DISTNAME}/bin/*.dll ${DISTNAME}/lib/
find . -name "lib*.la" -delete
@ -171,7 +171,7 @@ script: |
cp -rf contrib/windeploy $BUILD_DIR
cd $BUILD_DIR/windeploy
mkdir unsigned
cp $OUTDIR/litecoin-*setup-unsigned.exe unsigned/
cp $OUTDIR/zorro-*setup-unsigned.exe unsigned/
find . | sort | tar --no-recursion --mode='u+rw,go+r-w,a+X' --owner=0 --group=0 -c -T - | gzip -9n > ${OUTDIR}/${DISTNAME}-win-unsigned.tar.gz
mv ${OUTDIR}/${DISTNAME}-x86_64-*-debug.zip ${OUTDIR}/${DISTNAME}-win64-debug.zip
mv ${OUTDIR}/${DISTNAME}-i686-*-debug.zip ${OUTDIR}/${DISTNAME}-win32-debug.zip

8
contrib/linearize/README.md
View File

@ -1,5 +1,5 @@
# Linearize
Construct a linear, no-fork, best version of the Litecoin blockchain. The scripts
Construct a linear, no-fork, best version of the Zorro blockchain. The scripts
run using Python 3 but are compatible with Python 2.
## Step 1: Download hash list
@ -12,7 +12,7 @@ Required configuration file settings for linearize-hashes:
Optional config file setting for linearize-hashes:
* RPC: `host` (Default: `127.0.0.1`)
* RPC: `port` (Default: `9332`)
* RPC: `port` (Default: `18642`)
* Blockchain: `min_height`, `max_height`
* `rev_hash_bytes`: If true, the written block hash list will be
byte-reversed. (In other words, the hash returned by getblockhash will have its
@ -21,7 +21,7 @@ standalone hash lists but safe to use with linearize-data.py, which will output
the same data no matter which byte format is chosen.
The `linearize-hashes` script requires a connection, local or remote, to a
JSON-RPC server. Running `litecoind` or `litecoin-qt -server` will be sufficient.
JSON-RPC server. Running `zorrod` or `zorro-qt -server` will be sufficient.
## Step 2: Copy local block data
@ -39,7 +39,7 @@ will be printed.
respectively, to the current time and to the timestamp of the most recent block
written to the script's blockchain.
* `genesis`: The hash of the genesis block in the blockchain.
* `input`: litecoind blocks/ directory containing blkNNNNN.dat
* `input`: zorrod blocks/ directory containing blkNNNNN.dat
* `hashlist`: text file containing list of block hashes created by
linearize-hashes.py.
* `max_out_sz`: Maximum size for files created by the `output_file` option.

14
contrib/linearize/example-linearize.cfg
View File

@ -1,10 +1,10 @@
# litecoind RPC settings (linearize-hashes)
# zorrod RPC settings (linearize-hashes)
rpcuser=someuser
rpcpassword=somepassword
#datadir=~/.litecoin
#datadir=~/.zorro
host=127.0.0.1
port=9332
#port=19332
port=18642
#port=19063
# bootstrap.dat hashlist settings (linearize-hashes)
max_height=313000
@ -14,12 +14,12 @@ max_height=313000
# mainnet
netmagic=fbc0b6db
genesis=12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
input=/home/example/.litecoin/blocks
input=/home/example/.zorro/blocks
# testnet
#netmagic=fdd2c8f1
#genesis=4966625a4b2851d9fdee139e56211a0d88575f59ed816ff5e6a63deb4e3e29a0
#input=/home/example/.litecoin/testnet3/blocks
#genesis=d43857b4d0f5e0d7140a395ba91e2ba714925d1a575dcfeef12bf8c71a985622
#input=/home/example/.zorro/testnet3/blocks
# "output" option causes blockchain files to be written to the given location,
# with "output_file" ignored. If not used, "output_file" is used instead.

2
contrib/linearize/linearize-hashes.py
View File

@ -125,7 +125,7 @@ if __name__ == '__main__':
if 'host' not in settings:
settings['host'] = '127.0.0.1'
if 'port' not in settings:
settings['port'] = 9332
settings['port'] = 18642
if 'min_height' not in settings:
settings['min_height'] = 0
if 'max_height' not in settings:

2
contrib/macdeploy/README.md
View File

@ -11,5 +11,5 @@ This script should not be run manually, instead, after building as usual:
During the process, the disk image window will pop up briefly where the fancy
settings are applied. This is normal, please do not interfere.
When finished, it will produce `Litecoin-Core.dmg`.
When finished, it will produce `Zorro-Core.dmg`.

6
contrib/macdeploy/custom_dsstore.py
View File

@ -45,8 +45,8 @@ alias = Alias.from_bytes(icvp['backgroundImageAlias'])
alias.volume.name = package_name_ns
alias.volume.posix_path = '/Volumes/' + package_name_ns
alias.volume.disk_image_alias.target.filename = package_name_ns + '.temp.dmg'
alias.volume.disk_image_alias.target.carbon_path = 'Macintosh HD:Users:\x00litecoinuser:\x00Documents:\x00litecoin:\x00litecoin:\x00' + package_name_ns + '.temp.dmg'
alias.volume.disk_image_alias.target.posix_path = 'Users/litecoinuser/Documents/litecoin/litecoin/' + package_name_ns + '.temp.dmg'
alias.volume.disk_image_alias.target.carbon_path = 'Macintosh HD:Users:\x00zorrouser:\x00Documents:\x00zorro:\x00zorro:\x00' + package_name_ns + '.temp.dmg'
alias.volume.disk_image_alias.target.posix_path = 'Users/zorrouser/Documents/zorro/zorro/' + package_name_ns + '.temp.dmg'
alias.target.carbon_path = package_name_ns + ':.background:\x00background.tiff'
icvp['backgroundImageAlias'] = biplist.Data(alias.to_bytes())
ds['.']['icvp'] = icvp
@ -54,7 +54,7 @@ ds['.']['icvp'] = icvp
ds['.']['vSrn'] = ('long', 1)
ds['Applications']['Iloc'] = (370, 156)
ds['Litecoin-Qt.app']['Iloc'] = (128, 156)
ds['Zorro-Qt.app']['Iloc'] = (128, 156)
ds.flush()
ds.close()

2
contrib/macdeploy/detached-sig-create.sh
View File

@ -6,7 +6,7 @@
set -e
ROOTDIR=dist
BUNDLE="${ROOTDIR}/Litecoin-Qt.app"
BUNDLE="${ROOTDIR}/Zorro-Qt.app"
CODESIGN=codesign
TEMPDIR=sign.temp
TEMPLIST=${TEMPDIR}/signatures.txt

2
contrib/macdeploy/fancy.plist
View File

@ -22,7 +22,7 @@
<integer>370</integer>
<integer>156</integer>
</array>
<key>Litecoin-Qt.app</key>
<key>Zorro-Qt.app</key>
<array>
<integer>128</integer>
<integer>156</integer>

4
contrib/macdeploy/macdeployqtplus
View File

@ -155,7 +155,7 @@ class FrameworkInfo(object):
class ApplicationBundleInfo(object):
def __init__(self, path):
self.path = path
appName = "Litecoin-Qt"
appName = "Zorro-Qt"
self.binaryPath = os.path.join(path, "Contents", "MacOS", appName)
if not os.path.exists(self.binaryPath):
raise RuntimeError("Could not find bundle binary for " + path)
@ -603,7 +603,7 @@ else:
# ------------------------------------------------
target = os.path.join("dist", "Litecoin-Qt.app")
target = os.path.join("dist", "Zorro-Qt.app")
if verbose >= 2:
print("+ Copying source bundle +")

4
contrib/qos/README.md
View File

@ -1,5 +1,5 @@
### Qos ###
This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the Litecoin network. It limits outbound TCP traffic with a source or destination port of 9333, but not if the destination IP is within a LAN (defined as 192.168.x.x).
This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the Zorro network. It limits outbound TCP traffic with a source or destination port of 18641, but not if the destination IP is within a LAN (defined as 192.168.x.x).
This means one can have an always-on litecoind instance running, and another local litecoind/litecoin-qt instance which connects to this node and receives blocks from it.
This means one can have an always-on zorrod instance running, and another local zorrod/zorro-qt instance which connects to this node and receives blocks from it.

8
contrib/qos/tc.sh
View File

@ -6,7 +6,7 @@
IF="eth0"
#limit of the network interface in question
LINKCEIL="1gbit"
#limit outbound Litecoin protocol traffic to this rate
#limit outbound Zorro protocol traffic to this rate
LIMIT="160kbit"
#defines the address space for which you wish to disable rate limiting
LOCALNET="192.168.0.0/16"
@ -36,10 +36,10 @@ tc filter add dev ${IF} parent 1: protocol ip prio 2 handle 2 fw classid 1:11
# ret=$?
#done
#limit outgoing traffic to and from port 9333. but not when dealing with a host on the local network
#limit outgoing traffic to and from port 18641. but not when dealing with a host on the local network
# (defined by $LOCALNET)
# --set-mark marks packages matching these criteria with the number "2"
# these packages are filtered by the tc filter with "handle 2"
# this filter sends the packages into the 1:11 class, and this class is limited to ${LIMIT}
iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 9333 ! -d ${LOCALNET} -j MARK --set-mark 0x2
iptables -t mangle -A OUTPUT -p tcp -m tcp --sport 9333 ! -d ${LOCALNET} -j MARK --set-mark 0x2
iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 18641 ! -d ${LOCALNET} -j MARK --set-mark 0x2
iptables -t mangle -A OUTPUT -p tcp -m tcp --sport 18641 ! -d ${LOCALNET} -j MARK --set-mark 0x2

12
contrib/rpm/bitcoin.spec
View File

@ -332,9 +332,9 @@ if [ `%{_sbindir}/sestatus |grep -c "disabled"` -eq 0 ]; then
for selinuxvariant in %{selinux_variants}; do
%{_sbindir}/semodule -s ${selinuxvariant} -i %{_datadir}/selinux/${selinuxvariant}/bitcoin.pp &> /dev/null || :
done
%{_sbindir}/semanage port -a -t bitcoin_port_t -p tcp 9332
%{_sbindir}/semanage port -a -t bitcoin_port_t -p tcp 9333
%{_sbindir}/semanage port -a -t bitcoin_port_t -p tcp 19332
%{_sbindir}/semanage port -a -t bitcoin_port_t -p tcp 18642
%{_sbindir}/semanage port -a -t bitcoin_port_t -p tcp 18641
%{_sbindir}/semanage port -a -t bitcoin_port_t -p tcp 19063
%{_sbindir}/semanage port -a -t bitcoin_port_t -p tcp 19333
%{_sbindir}/fixfiles -R bitcoin-server restore &> /dev/null || :
%{_sbindir}/restorecon -R %{_localstatedir}/lib/bitcoin || :
@ -351,9 +351,9 @@ fi
# SELinux
if [ $1 -eq 0 ]; then
if [ `%{_sbindir}/sestatus |grep -c "disabled"` -eq 0 ]; then
%{_sbindir}/semanage port -d -p tcp 9332
%{_sbindir}/semanage port -d -p tcp 9333
%{_sbindir}/semanage port -d -p tcp 19332
%{_sbindir}/semanage port -d -p tcp 18642
%{_sbindir}/semanage port -d -p tcp 18641
%{_sbindir}/semanage port -d -p tcp 19063
%{_sbindir}/semanage port -d -p tcp 19333
for selinuxvariant in %{selinux_variants}; do
%{_sbindir}/semodule -s ${selinuxvariant} -r bitcoin &> /dev/null || :

2
contrib/seeds/README.md
View File

@ -8,7 +8,7 @@ and remove old versions as necessary.
The seeds compiled into the release are created from poolers's DNS seed data, like this:
curl -s https://www.litecoinpool.org/seeds.txt > seeds_main.txt
curl -s https://www.zorropool.org/seeds.txt > seeds_main.txt
python3 makeseeds.py < seeds_main.txt > nodes_main.txt
python3 generate-seeds.py . > ../../src/chainparamsseeds.h

6
contrib/seeds/generate-seeds.py
View File

@ -120,17 +120,17 @@ def main():
g.write('#ifndef BITCOIN_CHAINPARAMSSEEDS_H\n')
g.write('#define BITCOIN_CHAINPARAMSSEEDS_H\n')
g.write('/**\n')
g.write(' * List of fixed seed nodes for the litecoin network\n')
g.write(' * List of fixed seed nodes for the zorro network\n')
g.write(' * AUTOGENERATED by contrib/seeds/generate-seeds.py\n')
g.write(' *\n')
g.write(' * Each line contains a 16-byte IPv6 address and a port.\n')
g.write(' * IPv4 as well as onion addresses are wrapped inside a IPv6 address accordingly.\n')
g.write(' */\n')
with open(os.path.join(indir,'nodes_main.txt'),'r') as f:
process_nodes(g, f, 'pnSeed6_main', 9333)
process_nodes(g, f, 'pnSeed6_main', 18641)
g.write('\n')
with open(os.path.join(indir,'nodes_test.txt'),'r') as f:
process_nodes(g, f, 'pnSeed6_test', 19335)
process_nodes(g, f, 'pnSeed6_test', 19062)
g.write('#endif // BITCOIN_CHAINPARAMSSEEDS_H\n')
if __name__ == '__main__':

2
contrib/seeds/makeseeds.py
View File

@ -30,7 +30,7 @@ import collections
PATTERN_IPV4 = re.compile(r"^((\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})):(\d+)$")
PATTERN_IPV6 = re.compile(r"^\[([0-9a-z:]+)\]:(\d+)$")
PATTERN_ONION = re.compile(r"^([abcdefghijklmnopqrstuvwxyz234567]{16}\.onion):(\d+)$")
PATTERN_AGENT = re.compile(r"^(/Satoshi:0.13.(0|1|2|99)/|/LitecoinCore:0.13.(0|1|2|99)/|/LitecoinCore:0.14.(0|1|2|99)/|/LitecoinCore:0.15.(0|1|2|99)/)$")
PATTERN_AGENT = re.compile(r"^(/Satoshi:0.13.(0|1|2|99)/|/Zorro:0.13.(0|1|2|99)/|/Zorro:0.14.(0|1|2|99)/|/Zorro:0.15.(0|1|2|99)/)$")
def parseline(line):
sline = line.split()

326
contrib/seeds/nodes_main.txt
View File

@ -1,325 +1 @@
5.19.171.173:10333
5.39.64.7:9333
5.39.174.116:9333
5.45.69.13:9333
5.70.60.59:9333
5.83.128.199:9333
5.164.223.102:9333
5.255.86.7:9333
14.152.121.45:9333
14.162.208.157:9333
23.89.193.201:9333
23.92.221.66:9333
23.111.173.210:9333
23.227.204.78:9333
23.249.72.123:9333
24.32.201.82:9333
24.42.207.95:9333
24.113.234.227:9333
24.220.69.242:9333
31.220.7.131:9333
34.193.68.10:9333
35.194.152.236:33661
35.198.168.198:9333
36.249.108.60:9333
37.61.209.144:9333
37.97.181.86:9333
37.120.161.147:9333
37.148.195.230:9333
37.157.183.16:9333
37.221.209.222:9333
38.27.99.44:9333
38.108.92.49:9333
45.77.131.4:9333
45.77.248.13:9333
46.21.146.245:9333
46.28.201.68:9333
46.32.50.98:9333
46.37.191.113:9333
46.38.56.110:9333
46.229.168.201:9333
46.238.238.176:9333
46.254.240.86:10333
47.54.207.91:9333
47.55.95.227:9333
47.74.228.154:9333
47.89.48.243:9333
47.93.232.59:9333
47.187.1.83:9333
49.228.206.9:9333
50.63.166.27:9333
52.50.244.44:9333
52.229.171.108:9333
54.153.120.32:9333
54.166.208.190:9333
60.40.43.189:9333
60.191.106.148:9333
62.152.54.44:9333
62.152.58.16:9679
62.212.141.33:9333
63.141.246.42:9333
63.224.55.76:9333
64.34.231.140:9333
65.44.118.194:9333
65.189.240.126:9333
66.187.65.6:9333
66.196.5.33:9333
67.6.226.221:9333
68.97.201.76:9333
68.102.158.172:9333
68.114.233.44:9333
68.171.16.250:9333
68.198.36.180:9333
69.27.173.227:10333
69.112.110.247:9333
69.172.169.188:9333
70.63.170.86:9333
70.95.219.136:9333
70.118.197.69:9333
70.124.168.12:9333
71.120.16.218:9333
72.185.120.29:9333
72.234.251.203:9333
74.66.93.22:9333
74.80.235.180:10333
74.208.221.224:9333
76.12.247.45:9333
76.107.8.67:9333
77.37.156.166:9333
77.90.195.67:9333
77.110.11.52:9333
78.129.241.145:9333
79.135.200.27:9333
79.157.88.48:9333
80.83.191.199:9333
80.101.93.34:9333
80.122.43.78:9333
80.209.234.173:9333
80.211.132.197:9333
80.218.108.14:9333
81.24.101.140:9333
81.27.96.37:9333
81.94.197.250:9333
81.111.118.56:9333
82.202.162.5:9333
83.162.196.192:9333
83.183.110.251:9333
83.212.97.34:9333
84.85.102.113:9333
84.215.80.43:9333
84.234.52.190:37700
85.21.144.226:9333
85.143.137.206:9333
85.145.248.184:9333
85.194.238.130:9333
85.195.242.52:9333
85.214.68.122:9333
85.245.167.246:9333
86.2.87.19:9333
86.166.234.4:9333
87.79.94.221:9333
87.236.27.155:9333
87.249.207.89:9333
88.99.184.7:9333
88.191.51.7:9333
88.191.247.11:9333
88.202.202.221:9333
88.208.3.82:9333
89.22.104.48:9333
89.179.153.171:9333
89.212.75.6:9333
89.221.215.56:9333
89.221.241.44:9333
89.238.77.69:9333
91.109.112.90:9333
91.109.112.94:9333
91.126.118.164:9333
91.195.42.134:9333
91.197.44.43:9333
91.227.47.247:9333
91.228.155.63:9333
91.240.142.228:9333
92.63.88.125:9333
92.107.160.77:9333
92.222.180.15:9333
93.100.51.48:9333
93.104.210.112:9333
94.156.174.65:9333
94.210.62.73:9333
94.242.232.92:9333
94.254.21.81:9333
95.79.102.209:10333
95.154.90.99:9333
95.174.101.14:9333
95.211.136.86:9333
95.211.189.3:9333
95.213.137.3:9333
95.213.182.182:9333
96.19.28.91:9333
96.27.8.242:9333
97.91.224.251:9333
98.198.104.57:9333
99.69.17.146:9333
101.100.141.69:9333
103.56.136.105:9333
103.82.56.25:9333
103.203.50.58:9333
103.218.3.122:9333
103.242.66.36:3880
104.35.96.255:9333
104.219.251.145:9333
104.238.198.165:9333
104.239.230.131:28001
107.155.120.131:9333
107.180.69.235:9333
107.183.37.154:9333
108.170.26.210:11333
108.222.149.83:9333
109.75.172.40:9333
109.88.85.177:9333
109.111.178.181:10333
109.172.77.204:9333
109.195.179.63:9333
109.236.88.229:9333
110.4.40.147:9333
113.105.139.42:9333
116.62.224.23:15896
118.163.120.179:9333
118.163.122.208:9333
119.9.116.68:9333
119.15.100.120:9333
119.28.12.152:9333
119.28.177.66:9333
119.205.234.81:9333
120.92.117.37:10001
121.54.175.90:10333
121.54.175.191:10333
134.119.221.115:9333
136.30.44.86:9333
136.144.155.115:9333
138.197.156.129:9333
139.199.90.223:9333
143.89.121.207:9333
144.76.220.17:9002
147.229.13.210:9333
148.66.58.194:9333
152.186.36.86:9333
158.129.212.236:9333
158.129.212.251:9333
159.203.110.137:9333
159.253.21.46:9333
162.213.252.46:9333
166.70.94.106:9333
167.88.15.89:6001
168.235.81.143:9333
169.44.34.88:9333
169.57.145.101:9333
171.25.221.40:9333
172.104.104.203:9333
173.32.12.108:9333
173.51.177.2:9333
173.71.68.101:9333
173.80.190.86:9333
173.209.44.34:9333
173.209.53.114:9333
173.249.8.133:9333
173.255.204.124:9333
174.97.240.26:9333
174.117.242.205:9333
176.99.7.253:9333
176.102.192.8:9333
176.126.167.10:9333
176.221.43.121:9333
178.12.118.128:9333
178.15.158.237:9333
178.20.55.234:9333
178.155.51.54:9333
178.238.236.130:10333
182.255.61.202:28374
184.61.213.5:9333
184.70.33.190:9333
184.70.254.238:9333
184.95.48.202:9333
185.8.165.150:10333
185.15.92.18:10993
185.21.223.231:9333
185.25.120.91:9333
185.35.137.50:9333
185.50.213.124:9333
185.56.82.26:9333
185.64.104.2:9333
185.86.83.53:9333
185.101.218.140:9333
185.103.243.133:9333
185.127.17.125:9333
185.133.40.200:8234
185.141.24.127:9333
185.141.24.249:9333
185.148.162.35:10333
185.153.198.231:9333
185.154.15.191:9333
185.160.208.122:9333
185.176.141.11:9333
185.181.11.226:9333
185.183.161.35:9333
185.194.140.155:9333
185.220.33.46:9333
188.42.59.116:9333
188.72.214.6:9333
188.126.60.51:9333
188.138.33.33:9333
188.168.81.56:9333
188.172.155.81:9333
188.214.30.216:9333
188.241.58.79:9333
189.38.88.105:9333
190.117.133.172:9333
191.101.236.222:9333
192.111.152.58:9333
192.162.100.156:9333
192.187.116.245:9333
193.23.181.135:9333
193.106.30.173:9333
194.44.136.178:9333
194.63.143.197:9333
194.79.8.37:10333
194.88.106.40:9333
194.190.93.235:10333
195.68.159.181:9333
195.154.235.93:9333
195.169.138.2:9333
196.38.233.130:10333
198.40.48.22:9333
198.48.216.49:9933
198.98.48.192:9333
199.204.211.87:9333
203.60.2.67:9333
203.98.175.26:9333
203.98.175.43:9333
203.218.9.132:9333
205.185.120.58:9333
207.254.60.12:9333
209.41.186.78:9333
209.108.206.229:9333
209.133.221.159:9333
209.147.127.107:9333
210.183.15.227:9333
212.24.96.197:9333
212.47.252.13:9333
212.51.144.42:9333
213.113.232.47:9333
213.114.244.105:9333
213.141.154.201:9333
213.143.107.143:9333
213.168.13.151:9333
217.20.130.72:9333
217.103.32.213:9333
217.112.251.21:9333
217.122.192.92:9333
217.148.94.54:9333
219.88.232.127:9333
219.117.248.55:9333
220.194.43.237:9333
221.229.166.25:9333
222.236.44.46:9333
222.239.11.131:9333
179.228.234.7:18641

21
contrib/seeds/nodes_test.txt
View File

@ -1,20 +1 @@
5.9.31.67:19002
23.239.30.164:19335
35.159.10.86:19333
45.76.92.84:19335
52.221.228.214:19335
80.237.240.102:19335
81.169.237.132:19335
85.143.254.151:19335
85.214.99.201:19335
104.131.161.171:19335
104.243.38.34:19335
118.89.159.229:19335
138.201.195.202:19335
139.59.38.132:9898
162.213.252.66:19335
173.209.42.7:19335
188.42.59.116:19335
195.142.111.77:6753
198.58.102.18:19335
218.244.146.111:19335
179.228.234.7:19062

22
contrib/spendfrom/spendfrom.py
View File

@ -36,15 +36,15 @@ def check_json_precision():
raise RuntimeError("JSON encode/decode loses precision")
def determine_db_dir():
"""Return the default location of the litecoin data directory"""
"""Return the default location of the zorro data directory"""
if platform.system() == "Darwin":
return os.path.expanduser("~/Library/Application Support/Litecoin/")
return os.path.expanduser("~/Library/Application Support/Zorro/")
elif platform.system() == "Windows":
return os.path.join(os.environ['APPDATA'], "Litecoin")
return os.path.expanduser("~/.litecoin")
return os.path.join(os.environ['APPDATA'], "Zorro")
return os.path.expanduser("~/.zorro")
def read_bitcoin_config(dbdir):
"""Read the litecoin.conf file from dbdir, returns dictionary of settings"""
"""Read the zorro.conf file from dbdir, returns dictionary of settings"""
from ConfigParser import SafeConfigParser
class FakeSecHead(object):
@ -62,15 +62,15 @@ def read_bitcoin_config(dbdir):
return s
config_parser = SafeConfigParser()
config_parser.readfp(FakeSecHead(open(os.path.join(dbdir, "litecoin.conf"))))
config_parser.readfp(FakeSecHead(open(os.path.join(dbdir, "zorro.conf"))))
return dict(config_parser.items("all"))
def connect_JSON(config):
"""Connect to a litecoin JSON-RPC server"""
"""Connect to a zorro JSON-RPC server"""
testnet = config.get('testnet', '0')
testnet = (int(testnet) > 0) # 0/1 in config file, convert to True/False
if not 'rpcport' in config:
config['rpcport'] = 19332 if testnet else 9332
config['rpcport'] = 19063 if testnet else 18642
connect = "http://%s:%s@127.0.0.1:%s"%(config['rpcuser'], config['rpcpassword'], config['rpcport'])
try:
result = ServiceProxy(connect)
@ -224,15 +224,15 @@ def main():
parser = optparse.OptionParser(usage="%prog [options]")
parser.add_option("--from", dest="fromaddresses", default=None,
help="addresses to get litecoins from")
help="addresses to get zorros from")
parser.add_option("--to", dest="to", default=None,
help="address to get send litecoins to")
help="address to get send zorros to")
parser.add_option("--amount", dest="amount", default=None,
help="amount to send")
parser.add_option("--fee", dest="fee", default="0.0",
help="fee to include")
parser.add_option("--datadir", dest="datadir", default=determine_db_dir(),
help="location of litecoin.conf file with RPC username/password (default: %default)")
help="location of zorro.conf file with RPC username/password (default: %default)")
parser.add_option("--testnet", dest="testnet", default=False, action="store_true",
help="Use the test network")
parser.add_option("--dry_run", dest="dry_run", default=False, action="store_true",

2
contrib/testgen/README.md
View File

@ -1,6 +1,6 @@
### TestGen ###
Utilities to generate test vectors for the data-driven Litecoin tests.
Utilities to generate test vectors for the data-driven Zorro tests.
Usage:

12
contrib/tidy_datadir.sh
View File

@ -7,7 +7,7 @@ if [ -d "$1" ]; then
cd "$1"
else
echo "Usage: $0 <datadir>" >&2
echo "Removes obsolete Litecoin database files" >&2
echo "Removes obsolete Zorro database files" >&2
exit 1
fi
@ -19,22 +19,22 @@ if [ -f wallet.dat -a -f peers.dat -a -f chainstate/CURRENT -a -f blocks/index/C
case $LEVEL in
0)
echo "Error: no Litecoin datadir detected."
echo "Error: no Zorro datadir detected."
exit 1
;;
1)
echo "Detected old Litecoin datadir (before 0.7)."
echo "Detected old Zorro datadir (before 0.7)."
echo "Nothing to do."
exit 0
;;
2)
echo "Detected Litecoin 0.7 datadir."
echo "Detected Zorro 0.7 datadir."
;;
3)
echo "Detected Litecoin pre-0.8 datadir."
echo "Detected Zorro pre-0.8 datadir."
;;
4)
echo "Detected Litecoin 0.8 datadir."
echo "Detected Zorro 0.8 datadir."
;;
esac

4
contrib/windeploy/win-codesign.cert
View File

@ -1,7 +1,7 @@
Bag Attributes
friendlyName: Litecoin Foundation LTD.'s DigiCert Inc ID
friendlyName: Zorro Foundation LTD.'s DigiCert Inc ID
localKeyID: 2F AA 3A 86 85 98 1A 53 D5 23 F0 2E A0 22 CC 51 21 6D 78 B0
subject=/C=SG/L=Singapore/O=Litecoin Foundation LTD./CN=Litecoin Foundation LTD.
subject=/C=SG/L=Singapore/O=Zorro Foundation LTD./CN=Zorro Foundation LTD.
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Assured ID Code Signing CA
-----BEGIN CERTIFICATE-----
MIIFKjCCBBKgAwIBAgIQDvRXzQ2H3xYGUBDUDBeH/TANBgkqhkiG9w0BAQsFADBy

6
depends/README.md
View File

@ -12,9 +12,9 @@ For example:
make HOST=x86_64-w64-mingw32 -j4
A prefix will be generated that's suitable for plugging into Litecoin's
A prefix will be generated that's suitable for plugging into Zorro's
configure. In the above example, a dir named x86_64-w64-mingw32 will be
created. To use it for Litecoin:
created. To use it for Zorro:
./configure --prefix=`pwd`/depends/x86_64-w64-mingw32
@ -43,7 +43,7 @@ The following can be set when running make: make FOO=bar
BUILD_ID_SALT: Optional salt to use when generating build package ids
If some packages are not built, for example `make NO_WALLET=1`, the appropriate
options will be passed to litecoin's configure. In this case, `--disable-wallet`.
options will be passed to zorro's configure. In this case, `--disable-wallet`.
Additional targets:

4
depends/config.guess vendored
View File

@ -771,8 +771,8 @@ EOF
echo ${UNAME_MACHINE}-unknown-osf1
fi
exit ;;
parisc*:Lites*:*:*)
echo hppa1.1-hp-lites
parisc*:mZRR*:*:*)
echo hppa1.1-hp-mZRR
exit ;;
C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
echo c1-convex-bsd

2
depends/config.sub vendored
View File

@ -1404,7 +1404,7 @@ case $os in
| -ekkobsd* | -kfreebsd* | -freebsd* | -riscix* | -lynxos* \
| -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
| -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
| -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
| -udi* | -eabi* | -mZRR* | -ieee* | -go32* | -aux* \
| -chorusos* | -chorusrdb* | -cegcc* | -glidix* \
| -cygwin* | -msys* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
| -midipix* | -mingw32* | -mingw64* | -linux-gnu* | -linux-android* \

2
depends/packages/boost.mk
View File

@ -1,6 +1,6 @@
package=boost
$(package)_version=1_64_0
$(package)_download_path=https://dl.bintray.com/boostorg/release/1.64.0/source/
$(package)_download_path=https://boostorg.jfrog.io/artifactory/main/release/1.64.0/source/
$(package)_file_name=$(package)_$($(package)_version).tar.bz2
$(package)_sha256_hash=7bcc5caace97baa948931d712ea5f37038dbb1c5d89b43ad4def4ed7cb683332

32
doc/README.md
View File

@ -1,41 +1,41 @@
Litecoin Core
Zorro Core
=============
Setup
---------------------
Litecoin Core is the original Litecoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Litecoin transactions (which is currently more than 7 GBs); depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.
Zorro Core is the original Zorro client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Zorro transactions (which is currently more than 7 GBs); depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.
To download Litecoin Core, visit [litecoin.org](https://litecoin.org).
To download Zorro Core, visit [cryptogera.com](https://cryptogera.com).
Running
---------------------
The following are some helpful notes on how to run Litecoin on your native platform.
The following are some helpful notes on how to run Zorro on your native platform.
### Unix
Unpack the files into a directory and run:
- `bin/litecoin-qt` (GUI) or
- `bin/litecoind` (headless)
- `bin/zorro-qt` (GUI) or
- `bin/zorrod` (headless)
### Windows
Unpack the files into a directory, and then run litecoin-qt.exe.
Unpack the files into a directory, and then run zorro-qt.exe.
### OS X
Drag Litecoin-Core to your applications folder, and then run Litecoin-Core.
Drag Zorro-Core to your applications folder, and then run Zorro-Core.
### Need Help?
* See the documentation at the [Litecoin Wiki](https://litecoin.info/)
* See the documentation at the [Zorro Wiki](https://git.cryptogera.com/cryptogera/zorro/wiki/)
for help and more information.
* Ask for help on [#litecoin](http://webchat.freenode.net?channels=litecoin) on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net?channels=litecoin).
* Ask for help on the [LitecoinTalk](https://litecointalk.io/) forums.
* Ask for help on [#zorro](http://webchat.freenode.net?channels=zorro) on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net?channels=zorro).
* Ask for help on the [ZorroTalk](https://zorrotalk.io/) forums.
Building
---------------------
The following are developer notes on how to build Litecoin on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
The following are developer notes on how to build Zorro on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
- [OS X Build Notes](build-osx.md)
- [Unix Build Notes](build-unix.md)
@ -45,12 +45,12 @@ The following are developer notes on how to build Litecoin on your native platfo
Development
---------------------
The Litecoin repo's [root README](/README.md) contains relevant information on the development process and automated testing.
The Zorro repo's [root README](/README.md) contains relevant information on the development process and automated testing.
- [Developer Notes](developer-notes.md)
- [Release Notes](release-notes.md)
- [Release Process](release-process.md)
- [Source Code Documentation (External Link)](https://dev.visucore.com/litecoin/doxygen/)
- [Source Code Documentation (External Link)](https://dev.visucore.com/zorro/doxygen/)
- [Translation Process](translation_process.md)
- [Translation Strings Policy](translation_strings_policy.md)
- [Travis CI](travis-ci.md)
@ -61,8 +61,8 @@ The Litecoin repo's [root README](/README.md) contains relevant information on t
- [Benchmarking](benchmarking.md)
### Resources
* Discuss on the [LitecoinTalk](https://litecointalk.io/) forums.
* Discuss general Litecoin development on #litecoin-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=litecoin-dev).
* Discuss on the [ZorroTalk](https://zorrotalk.io/) forums.
* Discuss general Zorro development on #zorro-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=zorro-dev).
### Miscellaneous
- [Assets Attribution](assets-attribution.md)

2
doc/README_osx.md
View File

@ -92,6 +92,6 @@ build process to remain somewhat deterministic. Here's how it works:
that have been previously (deterministically) built in order to create a
final dmg.
- The Apple keyholder uses this unsigned app to create a detached signature,
using the script that is also included there. Detached signatures are available from this [repository](https://github.com/litecoin-project/litecoin-detached-sigs).
using the script that is also included there. Detached signatures are available from this [repository](https://git.cryptogera.com/cryptogera/zorro-detached-sigs).
- Builders feed the unsigned app + detached signature back into Gitian. It
uses the pre-built tools to recombine the pieces into a deterministic dmg.

14
doc/README_windows.txt
View File

@ -1,9 +1,9 @@
Litecoin Core
Zorro Core
=============
Intro
-----
Litecoin is a free open source peer-to-peer electronic cash system that is
Zorro is a free open source peer-to-peer electronic cash system that is
completely decentralized, without the need for a central server or trusted
parties. Users hold the crypto keys to their own money and transact directly
with each other, with the help of a P2P network to check for double-spending.
@ -11,13 +11,13 @@ with each other, with the help of a P2P network to check for double-spending.
Setup
-----
Unpack the files into a directory and run litecoin-qt.exe.
Unpack the files into a directory and run zorro-qt.exe.
Litecoin Core is the original Litecoin client and it builds the backbone of the network.
However, it downloads and stores the entire history of Litecoin transactions;
Zorro Core is the original Zorro client and it builds the backbone of the network.
However, it downloads and stores the entire history of Zorro transactions;
depending on the speed of your computer and network connection, the synchronization
process can take anywhere from a few hours to a day or more.
See the litecoin wiki at:
https://litecoin.info/
See the zorro wiki at:
https://git.cryptogera.com/cryptogera/zorro/wiki/
for more help and information.

4
doc/REST-interface.md
View File

@ -57,7 +57,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki
Example:
```
$ curl localhost:19332/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff7627ff72e5e8b0f71210f92ea7a4000c5d75-0.json 2>/dev/null | json_pp
$ curl localhost:19063/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff7627ff72e5e8b0f71210f92ea7a4000c5d75-0.json 2>/dev/null | json_pp
{
"chainHeight" : 325347,
"chaintipHash" : "00000000fb01a7f3745a717f8caebee056c484e6e0bfe4a9591c235bb70506fb",
@ -99,4 +99,4 @@ Only supports JSON as output format.
Risks
-------------
Running a web browser on the same node with a REST enabled litecoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:9332/rest/tx/1234567890.json">` which might break the nodes privacy.
Running a web browser on the same node with a REST enabled zorrod can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:18642/rest/tx/1234567890.json">` which might break the nodes privacy.

2
doc/assets-attribution.md
View File

@ -1 +1 @@
The list of assets used in the litecoin source and their attribution can now be found in [contrib/debian/copyright](../contrib/debian/copyright).
The list of assets used in the zorro source and their attribution can now be found in [contrib/debian/copyright](../contrib/debian/copyright).

275
doc/beginners-guide.md Normal file
View File

@ -0,0 +1,275 @@
[Português do Brasil](./guia-do-iniciante.md) | [English US](./beginners-guide.md)
# Zorro – Beginner's Guide
Introduction:
=========================================================
In this guide, we present a series of simple steps that anyone, even with no prior experience, can follow to start using their cryptocurrency.
Each coin created by CryptoGera is automatically made available in a public repository at https://git.cryptogera.com. This not only facilitates access to the source code and installation programs but also is crucial to ensure that the code has not been fraudulently manipulated, thus validating the integrity and legitimacy of the coin.
The specific repository for the Zorro coin is located at https://git.cryptogera.com/cryptogera/zorro.
Here, you will find the source code of the coin, along with binaries - compiled programs ready for installation and use on both Windows and Linux.
Below, we'll show you how to download and install this software, as well as provide an introduction to mining your first coins.
Download and install the coin's wallet
---------------------------------------------------------
To download the wallet, access the "Releases" tab in the coin's repository. For the Zorro coin, the address for "Releases" is:
[https://git.cryptogera.com/cryptogera/zorro/releases](https://git.cryptogera.com/cryptogera/zorro/releases)
On the mentioned page, you will find several zip packages containing the corresponding software.
For Windows users, download the "zorro-0.15.1-win64.zip" package. If the 64-bit version does not work on your system, try the 32-bit version, called "zorro-0.15.1-win32.zip".
> For Linux users, there is another available package called "zorro-0.15.1-linux-x86_64.zip", which requires a little more knowledge to install. If you are using Ubuntu, you can extract this file to the "/" folder of your computer so that the binaries are placed in "/usr/bin".
When you open the zip package, you will see an executable program with the ".exe" extension. This is the wallet installer for Windows. To start the installation, simply double-click on it. A window similar to this will appear:
![Image: Start Installation](first-steps/1_start_install.png)
The installation is similar to any other Windows installation you have performed before. Just follow the steps until the installation is complete. At the end, the Zorro coin wallet will be installed:
![Image: Finish Installation](first-steps/2_finish_install.png)
Running "Zorro Core" for the first time
---------------------------------------------------------
Let's open your newly installed wallet. To do this, simply click on the "Zorro Core" icon that appears in the menu of your Windows.
The first time you open your wallet, you will see a window similar to this one:
![Choose Storage Location](first-steps/3_choose_storage_location.png)
Although it is possible, we do not recommend changing the location (folder) where you will keep your wallet and blockchain data. Click the `OK` button to use the default location.
> If you are a beginner user, choosing a different location to store the data will bring implications that will make it difficult, for example, to create backups. Later in this guide, we will explain how to restore a backup of your wallet. However, if you have changed the folder where you store the wallet data, the instructions will not work.
Next, you will see a window similar to this one below, which shows that your wallet is trying to download blockchain data, that is, trying to synchronize its local database with the database of the Zorro coin's data network.
![Wallet Synchronization](first-steps/4_wallet_sync.png)
Bitcoin family coins, as is the case with the Zorro coin, operate on a distributed and decentralized network. This network is composed of "nodes", which are the wallets themselves interacting with each other. These "nodes" use a shared database among all of them, called the "blockchain".
Your wallet, every time it is opened, tries to connect to the other "nodes" of the network to synchronize blockchain data. This window will stay open and still, unable to synchronize, in two situations:
- When it does not find another "node" on the network, either due to a failed internet connection or because there are no other "nodes" online at the moment;
- When there are no new confirmed transactions, because no one is "mining" new blocks.
Since your coin is new, it is normal for it not to have anything to synchronize, so it will look like this. The first thing you need to do to "bring life" to the Zorro coin's blockchain is to mine the first block. See in the next step how to do this.
Mine your first block
---------------------------------------------------------
There are several ways to mine cryptocurrencies. The most common ones are:
- Through commands in the **debug window** of the coin's wallet;
- Through the command line, using the coin's client itself, in this case, the "zorro-cli";
- Using mining software in conjunction with an RPC server;
- Using mining software connected to a mining pool;
- Using mining equipment connected to a mining pool.
The first one is the fastest and simplest way, and although it is not efficient for blockchains that have already grown, it works very well for a newly created cryptocurrency.
To mine your first block, open the "Zorro Core" wallet you installed on Windows, access the "Help" menu, choose "Debug Window," and activate the "Console" tab:
![Debug Menu](first-steps/5_menu_debug_window_option.png)
In the space that appears at the bottom of the Console tab, type `generate 1`:
![Generate Command 1](first-steps/6_debug_window_generate_1.png)
Press ENTER and wait until a response appears. The waiting time for a response depends on your computer's processing power. You can send the `generate 1` command again before receiving a response, but know that each command sent triggers an additional mining process that requires more resources from your processor and can freeze your wallet. If this happens, you will need to close and reopen the "Zorro Core" wallet.
If you receive a response like this, with 2 empty brackets, it means that the block was not generated:
![Empty Response](first-steps/7_generate_1_empty_answer.png)
You may need to repeat the `generate 1` command several times until you find a block, which is normal. Just make sure not to send the `generate 1` command excessively to avoid freezing your wallet. Below, an example of several attempts made:
![Multiple Attempts](first-steps/8_generate_1_several_requests.png)
And finally, some successful responses after several attempts of the `generate 1` command. Note that when a block is successfully mined, a sequence of letters and numbers appears between brackets:
![Mining Success](first-steps/9_generate_1_success.png)
The blocks you just mined will appear in your wallet, each as a reward of 50 coins:
![Block Reward](first-steps/10_wallet_four_block_rewards.png)
But hold on, the reward coins are not yet yours. Each new mined block needs to receive 101 confirmations before being paid. For this, another 101 blocks need to be mined on the blockchain, by you or by other people. When this happens, these coins will automatically become available in your wallet.
> In Linux, the steps would be, first, to start the zorrod in daemon mode with the command `zorrod –daemon` and then use the client to generate the block with the command `zorro-cli generate 1`.
Protect your wallet with a password
---------------------------------------------------------
A newly installed wallet has no password, which puts your coins at risk if other people have access to your computer.
To create a new password, you need to access the "Settings" menu and choose "Encrypt Wallet":
![Encrypt Wallet Menu](first-steps/11_encrypt_wallet_menu.png)
Then, enter the new password (passphrase) to protect your wallet. The same password needs to be entered in both fields. It is recommended that the password be composed of at least 10 random characters or eight or more words. Take note of the password provided and click `OK` to proceed:
![Enter Password](first-steps/12_encrypt_wallet_passphrase.png)
Next, you will see this important warning, which alerts that if you forget your password, ALL COINS IN YOUR WALLET will be lost. If you wish to proceed with securing your wallet, answer "Yes":
![Important Warning](first-steps/13_encrypt_wallet_warning.png)
Finally, an alert appears that, even encrypted, your wallet is not invulnerable or malware-proof if your computer is infected. It also warns that, if you have made a backup before encrypting your wallet, it will be unprotected and, therefore, must be replaced by a new backup:
![Process Alert](first-steps/14_encrypt_wallet_process_alert.png)
Click the `OK` button, and the encryption process will begin. Do not interrupt the process, even if it seems stuck, as shown below:
![Frozen Process](first-steps/15_frozen_process.png)
This blank window will disappear on its own once the process is complete.
Done! Your wallet is encrypted, and from now on, whenever you send coins, you will need to enter this password (passphrase).
> Never forget the password for your wallet. Without it, you will never have access to the coins in your wallet.
In the future, how to change the wallet password?
---------------------------------------------------------
If the wallet is encrypted, in the "Settings" menu, you will see that the option "Encrypt Wallet" appears disabled, and the option "Change passphrase" is enabled. Use this option if you ever want to change your wallet password.
![Change Passphrase](first-steps/16_change_passphrase.png)
How to make a backup of your wallet
---------------------------------------------------------
In the drop-down menu that appears when clicking on "File," choose the "Backup Wallet..." option.
![Backup Wallet](first-steps/17_backup_wallet.png)
A dialog box will open for you to select the location where you want to save the backup file. Choose a secure location on your computer or an external storage device.
![Backup Dialog](first-steps/18_backup_dialog.png)
Give a meaningful name to the backup file, for example, "wallet_backup.dat." Click "Save" to complete the process.
Make sure the backup file has been successfully saved to the desired location.
**IMPORTANT!** It is crucial to store your backup file in a secure and preferably encrypted location, such as an external drive or trusted cloud storage service.
By following these steps, you will have backed up your Zorro Core wallet using the "File -> Backup Wallet" option on Windows. Make sure to make new backups regularly to ensure the security of your coins.
How to restore a backup of your wallet
---------------------------------------------------------
> **ALERT!** Never restore old backups on top of current wallets. When restoring a backup of your wallet, any transactions or balances made after this backup will be lost because the backup will overwrite the current state of your wallet with the state at the time the backup was made. Therefore, it is important to make backups regularly and maintain good security practices to protect your coins.
### Step 1: Close "Zorro Core"
If "Zorro Core" is open, close it completely before proceeding with the wallet restoration.
### Step 2: Locate the backup file
Make sure you have access to the backup file of your wallet. This will usually be a file with the extension ".dat" that you saved previously.
### Step 3: Access the "Zorro Core" data folder
Open Windows File Explorer.
Navigate to `%appdata%\zorro`. You can simply copy and paste `%appdata%\zorro` into the address bar of File Explorer and press Enter to quickly access this folder.
### Step 4: Backup your existing wallet (optional)
Before proceeding with the restoration, it is good practice to back up your existing wallet in case there is any important information you do not want to lose.
### Step 5: Replace the existing wallet file with the backup
In the `%appdata%\zorro` directory, find the existing wallet file, which usually has the name "wallet.dat."
Rename "wallet.dat" to "wallet-previous.dat" or copy this file to another folder as a precaution.
Copy the backup file of your wallet to the `%appdata%\zorro` directory and rename it to "wallet.dat."
### Step 6: Start "Zorro Core"
After replacing the wallet file, start "Zorro Core" again.
### Step 7: Verify the restoration was successful
Once "Zorro Core" is open, verify that your wallet has been restored correctly. Check the balance and transactions to ensure everything is as expected.
Sending and Receiving Coins
---------------------------------------------------------
"Zorro Core" offers a wide range of features to securely send and receive coins. Follow this step-by-step guide to learn how to use these functionalities:
### Sending Coins:
1. **Open "Zorro Core":**
- Launch the "Zorro Core" application on your computer.
2. **Access your Wallet:**
- After opening "Zorro Core," wait for your wallet to load. You will need to enter your password, if any, to unlock your wallet.
3. **Select "Send":**
- In the main menu, click on "Send" or find the send option in the navigation bar.
4. **Fill in Transaction Details:**
- Enter the "Zorro" address of the recipient in the designated field.
- Specify the amount you want to send in Zorro.
- Add a transaction fee if desired. A higher fee usually results in faster transaction confirmation.
5. **Review and Confirm:**
- Before sending the transaction, carefully review the details, such as the destination address and amount.
- Confirm the transaction and wait for confirmation on the blockchain.
### Receiving Coins:
1. **Get your "Zorro" Address:**
- In "Zorro Core," go to the "Receive" section or find the "Zorro" address in your wallet.
- Copy the provided "Zorro" address.
2. **Share your Address:**
- Paste the "Zorro" address in an email, message, or payment platform for the sender to send coins to you.
3. **Verify Receipt:**
- Wait for the sender to send the coins to your address.
- Once the coins are received, they will appear in your "Zorro Core" wallet.
4. **Blockchain Confirmation:**
- The transaction will be recorded on the blockchain, and after a few confirmations, the coins will be considered fully received and available for use.
Always remember to keep your private key secure and regularly back up your "Zorro Core" wallet to ensure the safety of your coins.
Final Recommendations
---------------------------------------------------------
- **Register an Internet domain for your coin:**
- Ensure a solid online presence by registering a dedicated domain for your coin. This makes it easier to create an official website and provides a central point for information and communication with the community.
- **Register your coin's brand:**
- Protect the identity and reputation of your coin by registering its brand. This helps avoid potential legal conflicts and promotes trust among users and investors.
- **Promote your coin in all possible venues:**
- Utilize social media, related forums, blogs, and other channels to promote your coin. The more people who know about your coin, the greater its adoption and appreciation.
- **Mine and encourage mining as much as possible:**
- Mining is essential for the security and decentralization of your coin. Encourage miners by offering fair rewards and promoting mining within your community.
- **Launch a blockchain explorer:**
- A blockchain explorer allows users to view transactions, account balances, and other important information about your coin. Make an explorer available to increase transparency and trust in your coin.
- **Develop a wallet app for your coin:**
- Facilitate access and use of your coin by developing a mobile wallet for iOS and Android devices. This allows users to manage their coins conveniently and securely.
- **Include your coin in mining pools:**
- Mining pools are groups of miners that combine their processing power to increase the chances of finding blocks and receiving rewards. List your coin in different pools to attract more miners.
- **List your coin on aggregators and exchanges:**
- Make your coin accessible for buying, selling, and trading by listing it on cryptocurrency exchange platforms and price aggregators. This increases the liquidity and visibility of your coin in the market.
- **Ready for an ICO?:**
- If you are planning an Initial Coin Offering (ICO), make sure to follow all regulations and legal requirements. Prepare a detailed whitepaper and establish a clear schedule for your ICO.

6
doc/benchmarking.md
View File

@ -1,11 +1,11 @@
Benchmarking
============
Litecoin Core has an internal benchmarking framework, with benchmarks
Zorro Core has an internal benchmarking framework, with benchmarks
for cryptographic algorithms such as SHA1, SHA256, SHA512 and RIPEMD160. As well as the rolling bloom filter.
After compiling litecoin-core, the benchmarks can be run with:
`src/bench/bench_litecoin`
After compiling zorro-core, the benchmarks can be run with:
`src/bench/bench_zorro`
The output will look similar to:
```

14
doc/build-openbsd.md
View File

@ -2,7 +2,7 @@ OpenBSD build guide
======================
(updated for OpenBSD 6.2)
This guide describes how to build litecoind and command-line utilities on OpenBSD.
This guide describes how to build zorrod and command-line utilities on OpenBSD.
OpenBSD is most commonly used as a server OS, so this guide does not contain instructions for building the GUI.
@ -18,7 +18,7 @@ pkg_add automake # (select highest version, e.g. 1.15)
pkg_add python # (select highest version, e.g. 3.6)
pkg_add boost
git clone https://github.com/litecoin-project/litecoin.git
git clone https://git.cryptogera.com/cryptogera/zorro.git
```
See [dependencies.md](dependencies.md) for a complete overview.
@ -26,7 +26,7 @@ See [dependencies.md](dependencies.md) for a complete overview.
GCC
-------
The default C++ compiler that comes with OpenBSD 6.2 is g++ 4.2.1. This version is old (from 2007), and is not able to compile the current version of Litecoin Core because it has no C++11 support. We'll install a newer version of GCC:
The default C++ compiler that comes with OpenBSD 6.2 is g++ 4.2.1. This version is old (from 2007), and is not able to compile the current version of Zorro Core because it has no C++11 support. We'll install a newer version of GCC:
```bash
pkg_add g++
@ -42,9 +42,9 @@ See "Berkeley DB" in [build-unix.md](build-unix.md#berkeley-db) for instructions
You cannot use the BerkeleyDB library from ports, for the same reason as boost above (g++/libstd++ incompatibility).
```bash
# Pick some path to install BDB to, here we create a directory within the litecoin directory
LITECOIN_ROOT=$(pwd)
BDB_PREFIX="${LITECOIN_ROOT}/db4"
# Pick some path to install BDB to, here we create a directory within the zorro directory
ZORRO_ROOT=$(pwd)
BDB_PREFIX="${ZORRO_ROOT}/db4"
mkdir -p $BDB_PREFIX
# Fetch the source and verify that it is not tampered with
@ -76,7 +76,7 @@ The change will only affect the current shell and processes spawned by it. To
make the change system-wide, change `datasize-cur` and `datasize-max` in
`/etc/login.conf`, and reboot.
### Building Litecoin Core
### Building Zorro Core
**Important**: use `gmake`, not `make`. The non-GNU `make` will exit with a horrible error.

32
doc/build-osx.md
View File

@ -28,17 +28,17 @@ If you want to build with ZeroMQ support
NOTE: Building with Qt4 is still supported, however, could result in a broken UI. Building with Qt5 is recommended.
Build Litecoin Core
Build Zorro Core
------------------------
1. Clone the litecoin source code and cd into `litecoin`
1. Clone the zorro source code and cd into `zorro`
git clone https://github.com/litecoin-project/litecoin
cd litecoin
git clone https://git.cryptogera.com/cryptogera/zorro
cd zorro
2. Build litecoin-core:
2. Build zorro-core:
Configure and build the headless litecoin binaries as well as the GUI (if Qt is found).
Configure and build the headless zorro binaries as well as the GUI (if Qt is found).
You can disable the GUI build by passing `--without-gui` to configure.
@ -57,37 +57,37 @@ Build Litecoin Core
Running
-------
Litecoin Core is now available at `./src/litecoind`
Zorro Core is now available at `./src/zorrod`
Before running, it's recommended you create an RPC configuration file.
echo -e "rpcuser=litecoinrpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/Litecoin/litecoin.conf"
echo -e "rpcuser=zorrorpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/Zorro/zorro.conf"
chmod 600 "/Users/${USER}/Library/Application Support/Litecoin/litecoin.conf"
chmod 600 "/Users/${USER}/Library/Application Support/Zorro/zorro.conf"
The first time you run litecoind, it will start downloading the blockchain. This process could take several hours.
The first time you run zorrod, it will start downloading the blockchain. This process could take several hours.
You can monitor the download process by looking at the debug.log file:
tail -f $HOME/Library/Application\ Support/Litecoin/debug.log
tail -f $HOME/Library/Application\ Support/Zorro/debug.log
Other commands:
-------
./src/litecoind -daemon # Starts the litecoin daemon.
./src/litecoin-cli --help # Outputs a list of command-line options.
./src/litecoin-cli help # Outputs a list of RPC commands when the daemon is running.
./src/zorrod -daemon # Starts the zorro daemon.
./src/zorro-cli --help # Outputs a list of command-line options.
./src/zorro-cli help # Outputs a list of RPC commands when the daemon is running.
Using Qt Creator as IDE
------------------------
You can use Qt Creator as an IDE, for litecoin development.
You can use Qt Creator as an IDE, for zorro development.
Download and install the community edition of [Qt Creator](https://www.qt.io/download/).
Uncheck everything except Qt Creator during the installation process.
1. Make sure you installed everything through Homebrew mentioned above
2. Do a proper ./configure --enable-debug
3. In Qt Creator do "New Project" -> Import Project -> Import Existing Project
4. Enter "litecoin-qt" as project name, enter src/qt as location
4. Enter "zorro-qt" as project name, enter src/qt as location
5. Leave the file selection as it is
6. Confirm the "summary page"
7. In the "Projects" tab select "Manage Kits..."

44
doc/build-unix.md
View File

@ -1,12 +1,12 @@
UNIX BUILD NOTES
====================
Some notes on how to build Litecoin Core in Unix.
Some notes on how to build Zorro Core in Unix.
(for OpenBSD specific instructions, see [build-openbsd.md](build-openbsd.md))
Note
---------------------
Always use absolute paths to configure and compile litecoin and the dependencies,
Always use absolute paths to configure and compile zorro and the dependencies,
for example, when specifying the path of the dependency:
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
@ -24,7 +24,7 @@ make
make install # optional
```
This will build litecoin-qt as well if the dependencies are met.
This will build zorro-qt as well if the dependencies are met.
Dependencies
---------------------
@ -55,7 +55,7 @@ Memory Requirements
--------------------
C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
memory available when compiling Litecoin Core. On systems with less, gcc can be
memory available when compiling Zorro Core. On systems with less, gcc can be
tuned to conserve memory with additional CXXFLAGS:
@ -94,7 +94,7 @@ BerkeleyDB 5.1 or later, which break binary wallet compatibility with the distri
are based on BerkeleyDB 4.8. If you do not care about wallet compatibility,
pass `--with-incompatible-bdb` to configure.
See the section "Disable-wallet mode" to build Litecoin Core without wallet.
See the section "Disable-wallet mode" to build Zorro Core without wallet.
Optional (see --with-miniupnpc and --enable-upnp-default):
@ -107,7 +107,7 @@ ZMQ dependencies (provides ZMQ API 4.x):
Dependencies for the GUI: Ubuntu & Debian
-----------------------------------------
If you want to build Litecoin-Qt, make sure that the required packages for Qt development
If you want to build Zorro-Qt, make sure that the required packages for Qt development
are installed. Either Qt 5 or Qt 4 are necessary to build the GUI.
If both Qt 4 and Qt 5 are installed, Qt 5 will be used. Pass `--with-gui=qt4` to configure to choose Qt4.
To build without GUI pass `--without-gui`.
@ -124,7 +124,7 @@ libqrencode (optional) can be installed with:
sudo apt-get install libqrencode-dev
Once these are installed, they will be found by configure and a litecoin-qt executable will be
Once these are installed, they will be found by configure and a zorro-qt executable will be
built by default.
Dependency Build Instructions: Fedora
@ -147,7 +147,7 @@ libqrencode (optional) can be installed with:
Notes
-----
The release is built with GCC and then "strip litecoind" to strip the debug
The release is built with GCC and then "strip zorrod" to strip the debug
symbols, which reduces the executable size by about 90%.
@ -168,10 +168,10 @@ Berkeley DB
It is recommended to use Berkeley DB 4.8. If you have to build it yourself:
```bash
LITECOIN_ROOT=$(pwd)
ZORRO_ROOT=$(pwd)
# Pick some path to install BDB to, here we create a directory within the litecoin directory
BDB_PREFIX="${LITECOIN_ROOT}/db4"
# Pick some path to install BDB to, here we create a directory within the zorro directory
BDB_PREFIX="${ZORRO_ROOT}/db4"
mkdir -p $BDB_PREFIX
# Fetch the source and verify that it is not tampered with
@ -186,8 +186,8 @@ cd db-4.8.30.NC/build_unix/
../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
make install
# Configure Litecoin Core to use our own-built instance of BDB
cd $LITECOIN_ROOT
# Configure Zorro Core to use our own-built instance of BDB
cd $ZORRO_ROOT
./autogen.sh
./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" # (other args...)
```
@ -205,7 +205,7 @@ If you need to build Boost yourself:
Security
--------
To help make your litecoin installation more secure by making certain attacks impossible to
To help make your zorro installation more secure by making certain attacks impossible to
exploit even if a vulnerability is found, binaries are hardened by default.
This can be disabled with:
@ -229,7 +229,7 @@ Hardening enables the following features:
To test that you have built PIE executable, install scanelf, part of paxutils, and use:
scanelf -e ./litecoin
scanelf -e ./zorro
The output should contain:
@ -238,13 +238,13 @@ Hardening enables the following features:
* Non-executable Stack
If the stack is executable then trivial stack based buffer overflow exploits are possible if
vulnerable buffers are found. By default, litecoin should be built with a non-executable stack
vulnerable buffers are found. By default, zorro should be built with a non-executable stack
but if one of the libraries it uses asks for an executable stack or someone makes a mistake
and uses a compiler extension which requires an executable stack, it will silently build an
executable without the non-executable stack protection.
To verify that the stack is non-executable after compiling use:
`scanelf -e ./litecoin`
`scanelf -e ./zorro`
the output should contain:
STK/REL/PTL
@ -254,7 +254,7 @@ Hardening enables the following features:
Disable-wallet mode
--------------------
When the intention is to run only a P2P node without a wallet, litecoin may be compiled in
When the intention is to run only a P2P node without a wallet, zorro may be compiled in
disable-wallet mode with:
./configure --disable-wallet
@ -276,8 +276,8 @@ Setup and Build Example: Arch Linux
This example lists the steps necessary to setup and build a command line only, non-wallet distribution of the latest changes on Arch Linux:
pacman -S git base-devel boost libevent python
git clone https://github.com/litecoin-project/litecoin.git
cd litecoin/
git clone https://git.cryptogera.com/cryptogera/zorro.git
cd zorro/
./autogen.sh
./configure --disable-wallet --without-gui --without-miniupnpc
make check
@ -286,7 +286,7 @@ Note:
Enabling wallet support requires either compiling against a Berkeley DB newer than 4.8 (package `db`) using `--with-incompatible-bdb`,
or building and depending on a local version of Berkeley DB 4.8. The readily available Arch Linux packages are currently built using
`--with-incompatible-bdb` according to the [PKGBUILD](https://projects.archlinux.org/svntogit/community.git/tree/bitcoin/trunk/PKGBUILD).
As mentioned above, when maintaining portability of the wallet between the standard Litecoin Core distributions and independently built
As mentioned above, when maintaining portability of the wallet between the standard Zorro Core distributions and independently built
node software is desired, Berkeley DB 4.8 must be used.
@ -334,7 +334,7 @@ For the wallet (optional):
This will give a warning "configure: WARNING: Found Berkeley DB other
than 4.8; wallets opened by this build will not be portable!", but as FreeBSD never
had a binary release, this may not matter. If backwards compatibility
with 4.8-built Litecoin Core is needed follow the steps under "Berkeley DB" above.
with 4.8-built Zorro Core is needed follow the steps under "Berkeley DB" above.
Then build using:

34
doc/build-windows.md
View File

@ -1,12 +1,12 @@
WINDOWS BUILD NOTES
====================
Below are some notes on how to build Litecoin Core for Windows.
Below are some notes on how to build Zorro Core for Windows.
The options known to work for building Litecoin Core on Windows are:
The options known to work for building Zorro Core on Windows are:
* On Linux using the [Mingw-w64](https://mingw-w64.org/doku.php) cross compiler tool chain. Ubuntu Trusty 14.04 is recommended
and is the platform used to build the Litecoin Core Windows release binaries.
and is the platform used to build the Zorro Core Windows release binaries.
* On Windows using [Windows
Subsystem for Linux (WSL)](https://msdn.microsoft.com/commandline/wsl/about) and the Mingw-w64 cross compiler tool chain.
@ -53,7 +53,7 @@ Cross-compilation for Ubuntu and Windows Subsystem for Linux
------------------------------------------------------------
At the time of writing the Windows Subsystem for Linux installs Ubuntu Xenial 16.04. The Mingw-w64 package
for Ubuntu Xenial does not produce working executables for some of the Litecoin Core applications.
for Ubuntu Xenial does not produce working executables for some of the Zorro Core applications.
It is possible to build on Ubuntu Xenial by installing the cross compiler packages from Ubuntu Zesty, see the steps below.
Building on Ubuntu Zesty 17.04 up to 17.10 has been verified to work.
@ -98,15 +98,15 @@ Ubuntu Zesty 17.04 <sup>[2](#footnote2)</sup>:
Once the tool chain is installed the build steps are common:
Note that for WSL the Litecoin Core source path MUST be somewhere in the default mount file system, for
example /usr/src/litecoin, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
Note that for WSL the Zorro Core source path MUST be somewhere in the default mount file system, for
example /usr/src/zorro, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
This means you cannot use a directory that located directly on the host Windows file system to perform the build.
The next three steps are an example of how to acquire the source in an appropriate way.
cd /usr/src
sudo git clone https://github.com/litecoin-project/litecoin.git
sudo chmod -R a+rw litecoin
sudo git clone https://git.cryptogera.com/cryptogera/zorro.git
sudo chmod -R a+rw zorro
Once the source code is ready the build steps are below.
@ -128,15 +128,15 @@ For Ubuntu Xenial 16.04, Ubuntu Zesty 17.04 and Windows Subsystem for Linux <sup
sudo update-alternatives --config i686-w64-mingw32-g++ # Set the default mingw32 g++ compiler option to posix.
Note that for WSL the Litecoin Core source path MUST be somewhere in the default mount file system, for
example /usr/src/litecoin, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
Note that for WSL the Zorro Core source path MUST be somewhere in the default mount file system, for
example /usr/src/zorro, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
This means you cannot use a directory that located directly on the host Windows file system to perform the build.
The next three steps are an example of how to acquire the source in an appropriate way.
cd /usr/src
sudo git clone https://github.com/litecoin-project/litecoin.git
sudo chmod -R a+rw litecoin
sudo git clone https://git.cryptogera.com/cryptogera/zorro.git
sudo chmod -R a+rw zorro
Then build using:
@ -158,15 +158,15 @@ Installation
After building using the Windows subsystem it can be useful to copy the compiled
executables to a directory on the windows drive in the same directory structure
as they appear in the release `.zip` archive. This can be done in the following
way. This will install to `c:\workspace\litecoin`, for example:
way. This will install to `c:\workspace\zorro`, for example:
make install DESTDIR=/mnt/c/workspace/litecoin
make install DESTDIR=/mnt/c/workspace/zorro
Footnotes
---------
<a name="footnote1">1</a>: There is currently a bug in the 64 bit Mingw-w64 cross compiler packaged for WSL/Ubuntu Xenial 16.04 that
causes two of the litecoin executables to crash shortly after start up. The bug is related to the
causes two of the zorro executables to crash shortly after start up. The bug is related to the
-fstack-protector-all g++ compiler flag which is used to mitigate buffer overflows.
Installing the Mingw-w64 packages from the Ubuntu 17 distribution solves the issue, however, this is not
an officially supported approach and it's only recommended if you are prepared to reinstall WSL/Ubuntu should
@ -176,5 +176,5 @@ something break.
compiler options to allow a choice between either posix or win32 threads. The default option is win32 threads which is the more
efficient since it will result in binary code that links directly with the Windows kernel32.lib. Unfortunately, the headers
required to support win32 threads conflict with some of the classes in the C++11 standard library in particular std::mutex.
It's not possible to build the litecoin code using the win32 version of the Mingw-w64 cross compilers (at least not without
modifying headers in the litecoin source code).
It's not possible to build the zorro code using the win32 version of the Mingw-w64 cross compilers (at least not without
modifying headers in the zorro source code).

28
doc/developer-notes.md
View File

@ -151,7 +151,7 @@ to see it.
**testnet and regtest modes**
Run with the -testnet option to run with "play litecoins" on the test network, if you
Run with the -testnet option to run with "play zorros" 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.
@ -160,7 +160,7 @@ that run in -regtest mode.
**DEBUG_LOCKORDER**
Litecoin Core is a multithreaded application, and deadlocks or other multithreading bugs
Zorro Core 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.
@ -195,7 +195,7 @@ Threads
- ThreadMapPort : Universal plug-and-play startup/shutdown
- ThreadSocketHandler : Sends/Receives data from peers on port 9333.
- ThreadSocketHandler : Sends/Receives data from peers on port 18641.
- ThreadOpenAddedConnections : Opens network connections to added nodes.
@ -207,9 +207,9 @@ Threads
- ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms.
- ThreadRPCServer : Remote procedure call handler, listens on port 9332 for connections and services them.
- ThreadRPCServer : Remote procedure call handler, listens on port 18642 for connections and services them.
- BitcoinMiner : Generates litecoins (if wallet is enabled).
- BitcoinMiner : Generates zorros (if wallet is enabled).
- Shutdown : Does an orderly shutdown of everything.
@ -219,7 +219,7 @@ Ignoring IDE/editor files
In closed-source environments in which everyone uses the same IDE it is common
to add temporary files it produces to the project-wide `.gitignore` file.
However, in open source software such as Litecoin Core, where everyone uses
However, in open source software such as Zorro Core, where everyone uses
their own editors/IDE/tools, it is less common. Only you know what files your
editor produces and this may change from version to version. The canonical way
to do this is thus to create your local gitignore. Add this to `~/.gitconfig`:
@ -249,9 +249,9 @@ Development guidelines
============================
A few non-style-related recommendations for developers, as well as points to
pay attention to for reviewers of Litecoin Core code.
pay attention to for reviewers of Zorro Core code.
General Litecoin Core
General Zorro Core
----------------------
- New features should be exposed on RPC first, then can be made available in the GUI
@ -361,7 +361,7 @@ Strings and formatting
- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
- *Rationale*: Litecoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion
- *Rationale*: Zorro Core uses tinyformat, which is type safe. Leave them out to avoid confusion
Variable names
--------------
@ -467,12 +467,12 @@ Subtrees
Several parts of the repository are subtrees of software maintained elsewhere.
Some of these are maintained by active developers of Litecoin Core, in which case changes should probably go
Some of these are maintained by active developers of Zorro Core, in which case changes should probably go
directly upstream without being PRed directly against the project. They will be merged back in the next
subtree merge.
Others are external projects without a tight relationship with our project. Changes to these should also
be sent upstream but bugfixes may also be prudent to PR against Litecoin Core so that they can be integrated
be sent upstream but bugfixes may also be prudent to PR against Zorro Core so that they can be integrated
quickly. Cosmetic changes should be purely taken upstream.
There is a tool in contrib/devtools/git-subtree-check.sh to check a subtree directory for consistency with
@ -535,7 +535,7 @@ Git and GitHub tips
[remote "upstream-pull"]
fetch = +refs/pull/*:refs/remotes/upstream-pull/*
url = git@github.com:litecoin-project/litecoin.git
url = git@github.com:zorro-project/zorro.git
This will add an `upstream-pull` remote to your git repository, which can be fetched using `git fetch --all`
or `git fetch upstream-pull`. Afterwards, you can use `upstream-pull/NUMBER/head` in arguments to `git show`,
@ -583,7 +583,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
- Try not to overload methods on argument type. E.g. don't make `getblock(true)` and `getblock("hash")`
do different things.
- *Rationale*: This is impossible to use with `litecoin-cli`, and can be surprising to users.
- *Rationale*: This is impossible to use with `zorro-cli`, and can be surprising to users.
- *Exception*: Some RPC calls can take both an `int` and `bool`, most notably when a bool was switched
to a multi-value, or due to other historical reasons. **Always** have false map to 0 and
@ -602,7 +602,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
- Add every non-string RPC argument `(method, idx, name)` to the table `vRPCConvertParams` in `rpc/client.cpp`.
- *Rationale*: `litecoin-cli` and the GUI debug console use this table to determine how to
- *Rationale*: `zorro-cli` and the GUI debug console use this table to determine how to
convert a plaintext command line to JSON. If the types don't match, the method can be unusable
from there.

16
doc/dnsseed-policy.md
View File

@ -1,12 +1,12 @@
Expectations for DNS Seed operators
====================================
Litecoin Core attempts to minimize the level of trust in DNS seeds,
Zorro Core 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 Litecoin community.
level of trust within the Zorro community.
Other implementations of Litecoin software may also use the same
Other implementations of Zorro 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 dnsseeds.
@ -16,7 +16,7 @@ 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 Litecoin nodes from the public network to the best of the
functioning Zorro 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
@ -26,7 +26,7 @@ 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 Litecoin
for the operation of the service or urgent health of the Zorro
network and must not be retained longer than necessary nor disclosed
to any third party.
@ -42,13 +42,13 @@ details of their operating practices.
related to the DNS seed operation.
If these expectations cannot be satisfied the operator should
discontinue providing services and contact the active Litecoin
discontinue providing services and contact the active Zorro
Core development team as well as posting on
[litecoin-dev](https://groups.google.com/forum/#!forum/litecoin-dev).
[zorro-dev](https://groups.google.com/forum/#!forum/zorro-dev).
Behavior outside of these expectations may be reasonable in some
situations but should be discussed in public in advance.
See also
----------
- [litecoin-seeder](https://github.com/pooler/litecoin-seeder) is a reference implementation of a DNS seed.
- [zorro-seeder](https://github.com/pooler/zorro-seeder) is a reference implementation of a DNS seed.

6
doc/files.md
View File

@ -1,14 +1,14 @@
* banlist.dat: stores the IPs/Subnets of banned nodes
* litecoin.conf: contains configuration settings for litecoind or litecoin-qt
* litecoind.pid: stores the process id of litecoind while running
* zorro.conf: contains configuration settings for zorrod or zorro-qt
* zorrod.pid: stores the process id of zorrod while running
* blocks/blk000??.dat: block data (custom, 128 MiB per file); since 0.8.0
* blocks/rev000??.dat; block undo data (custom); since 0.8.0 (format changed since pre-0.8)
* blocks/index/*; block index (LevelDB); since 0.8.0
* chainstate/*; block chain state database (LevelDB); since 0.8.0
* database/*: BDB database environment; only used for wallet since 0.8.0
* db.log: wallet database log file
* debug.log: contains debug information and general logging generated by litecoind or litecoin-qt
* debug.log: contains debug information and general logging generated by zorrod or zorro-qt
* fee_estimates.dat: stores statistics used to estimate minimum transaction fees and priorities required for confirmation; since 0.10.0
* mempool.dat: dump of the mempool's transactions; since 0.14.0.
* peers.dat: peer IP address database (custom format); since 0.7.0

BIN
doc/first-steps/10_wallet_four_block_rewards.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

BIN
doc/first-steps/11_encrypt_wallet_menu.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
doc/first-steps/12_encrypt_wallet_passphrase.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.9 KiB

BIN
doc/first-steps/13_encrypt_wallet_warning.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.9 KiB

BIN
doc/first-steps/14_encrypt_wallet_process_alert.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
doc/first-steps/15_frozen_process.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.0 KiB

BIN
doc/first-steps/16_change_passphrase.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
doc/first-steps/17_backup_wallet.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
doc/first-steps/18_backup_dialog.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
doc/first-steps/1_start_install.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
doc/first-steps/2_finish_install.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
doc/first-steps/3_choose_storage_location.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
doc/first-steps/4_wallet_sync.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
doc/first-steps/5_menu_debug_window_option.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
doc/first-steps/6_debug_window_generate_1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
doc/first-steps/7_generate_1_empty_answer.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
doc/first-steps/8_generate_1_several_requests.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 25 KiB

BIN
doc/first-steps/9_generate_1_success.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

10
doc/fuzzing.md
View File

@ -1,7 +1,7 @@
Fuzz-testing Litecoin Core
Fuzz-testing Zorro Core
==========================
A special test harness `test_litecoin_fuzzy` is provided to provide an easy
A special test harness `test_zorro_fuzzy` is provided to provide an easy
entry point for fuzzers and the like. In this document we'll describe how to
use it with AFL.
@ -20,13 +20,13 @@ export AFLPATH=$PWD
Instrumentation
----------------
To build Litecoin Core using AFL instrumentation (this assumes that the
To build Zorro Core using AFL instrumentation (this assumes that the
`AFLPATH` was set as above):
```
./configure --disable-ccache --disable-shared --enable-tests CC=${AFLPATH}/afl-gcc CXX=${AFLPATH}/afl-g++
export AFL_HARDEN=1
cd src/
make test/test_litecoin_fuzzy
make test/test_zorro_fuzzy
```
We disable ccache because we don't want to pollute the ccache with instrumented
objects, and similarly don't want to use non-instrumented cached objects linked
@ -65,7 +65,7 @@ Fuzzing
To start the actual fuzzing use:
```
$AFLPATH/afl-fuzz -i ${AFLIN} -o ${AFLOUT} -m52 -- test/test_litecoin_fuzzy
$AFLPATH/afl-fuzz -i ${AFLIN} -o ${AFLOUT} -m52 -- test/test_zorro_fuzzy
```
You may have to change a few kernel parameters to test optimally - `afl-fuzz`

54
doc/gitian-building.md
View File

@ -1,9 +1,9 @@
Gitian building
================
*Setup instructions for a Gitian build of Litecoin Core using a Debian VM or physical system.*
*Setup instructions for a Gitian build of Zorro Core using a Debian VM or physical system.*
Gitian is the deterministic build process that is used to build the Litecoin
Gitian is the deterministic build process that is used to build the Zorro
Core executables. It provides a way to be reasonably sure that the
executables are really built from the source on GitHub. It also makes sure that
the same, tested dependencies are used and statically built into the executable.
@ -11,7 +11,7 @@ the same, tested dependencies are used and statically built into the executable.
Multiple developers build the source code by following a specific descriptor
("recipe"), cryptographically sign the result, and upload the resulting signature.
These results are compared and only if they match, the build is accepted and uploaded
to litecoin.org.
to cryptogera.com.
More independent Gitian builders are needed, which is why this guide exists.
It is preferred you follow these steps yourself instead of using someone else's
@ -26,7 +26,7 @@ Table of Contents
- [Installing Gitian](#installing-gitian)
- [Setting up the Gitian image](#setting-up-the-gitian-image)
- [Getting and building the inputs](#getting-and-building-the-inputs)
- [Building Litecoin Core](#building-litecoin-core)
- [Building Zorro Core](#building-zorro-core)
- [Building an alternative repository](#building-an-alternative-repository)
- [Signing externally](#signing-externally)
- [Uploading signatures](#uploading-signatures)
@ -310,12 +310,12 @@ cd ..
**Note**: When sudo asks for a password, enter the password for the user *debian* not for *root*.
Clone the git repositories for litecoin and Gitian.
Clone the git repositories for zorro and Gitian.
```bash
git clone https://github.com/devrandom/gitian-builder.git
git clone https://github.com/litecoin-project/litecoin
git clone https://github.com/litecoin-project/gitian.sigs.ltc.git
git clone https://git.cryptogera.com/cryptogera/zorro
git clone https://github.com/zorro-project/gitian.sigs.ltc.git
```
Setting up the Gitian image
@ -344,16 +344,16 @@ Getting and building the inputs
At this point you have two options, you can either use the automated script (found in [contrib/gitian-build.sh](/contrib/gitian-build.sh)) or you could manually do everything by following this guide. If you're using the automated script, then run it with the "--setup" command. Afterwards, run it with the "--build" command (example: "contrib/gitian-build.sh -b signer 0.13.0"). Otherwise ignore this.
Follow the instructions in [doc/release-process.md](release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change)
in the litecoin repository under 'Fetch and create inputs' to install sources which require
in the zorro repository under 'Fetch and create inputs' to install sources which require
manual intervention. Also optionally follow the next step: 'Seed the Gitian sources cache
and offline git repositories' which will fetch the remaining files required for building
offline.
Building Litecoin Core
Building Zorro Core
----------------
To build Litecoin Core (for Linux, OS X and Windows) just follow the steps under 'perform
Gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the litecoin repository.
To build Zorro Core (for Linux, OS X and Windows) just follow the steps under 'perform
Gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the zorro repository.
This may take some time as it will build all the dependencies needed for each descriptor.
These dependencies will be cached after a successful build to avoid rebuilding them when possible.
@ -367,12 +367,12 @@ tail -f var/build.log
Output from `gbuild` will look something like
Initialized empty Git repository in /home/debian/gitian-builder/inputs/litecoin/.git/
Initialized empty Git repository in /home/debian/gitian-builder/inputs/zorro/.git/
remote: Counting objects: 57959, done.
remote: Total 57959 (delta 0), reused 0 (delta 0), pack-reused 57958
Receiving objects: 100% (57959/57959), 53.76 MiB | 484.00 KiB/s, done.
Resolving deltas: 100% (41590/41590), done.
From https://github.com/litecoin-project/litecoin
From https://git.cryptogera.com/cryptogera/zorro
... (new tags, new branch etc)
--- Building for trusty amd64 ---
Stopping target if it is up
@ -398,18 +398,18 @@ and inputs.
For example:
```bash
URL=https://github.com/thrasher-/litecoin.git
URL=https://github.com/thrasher-/zorro.git
COMMIT=2014_03_windows_unicode_path
./bin/gbuild --commit litecoin=${COMMIT} --url litecoin=${URL} ../litecoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gbuild --commit litecoin=${COMMIT} --url litecoin=${URL} ../litecoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gbuild --commit litecoin=${COMMIT} --url litecoin=${URL} ../litecoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gbuild --commit zorro=${COMMIT} --url zorro=${URL} ../zorro/contrib/gitian-descriptors/gitian-linux.yml
./bin/gbuild --commit zorro=${COMMIT} --url zorro=${URL} ../zorro/contrib/gitian-descriptors/gitian-win.yml
./bin/gbuild --commit zorro=${COMMIT} --url zorro=${URL} ../zorro/contrib/gitian-descriptors/gitian-osx.yml
```
Building fully offline
-----------------------
For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository
and the litecoin git repository with the desired tag must both be available locally, and then gbuild must be
and the zorro git repository with the desired tag must both be available locally, and then gbuild must be
told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or
manually disabling gitian-builder's use of apt-get to update the VM build environment.
@ -428,7 +428,7 @@ cd /path/to/gitian-builder
LXC_ARCH=amd64 LXC_SUITE=trusty on-target -u root apt-get update
LXC_ARCH=amd64 LXC_SUITE=trusty on-target -u root \
-e DEBIAN_FRONTEND=noninteractive apt-get --no-install-recommends -y install \
$( sed -ne '/^packages:/,/[^-] .*/ {/^- .*/{s/"//g;s/- //;p}}' ../litecoin/contrib/gitian-descriptors/*|sort|uniq )
$( sed -ne '/^packages:/,/[^-] .*/ {/^- .*/{s/"//g;s/- //;p}}' ../zorro/contrib/gitian-descriptors/*|sort|uniq )
LXC_ARCH=amd64 LXC_SUITE=trusty on-target -u root apt-get -q -y purge grub
LXC_ARCH=amd64 LXC_SUITE=trusty on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade
```
@ -448,12 +448,12 @@ Then when building, override the remote URLs that gbuild would otherwise pull fr
```bash
cd /some/root/path/
git clone https://github.com/litecoin-project/litecoin-detached-sigs.git
git clone https://git.cryptogera.com/cryptogera/zorro-detached-sigs.git
BTCPATH=/some/root/path/litecoin
SIGPATH=/some/root/path/litecoin-detached-sigs
BTCPATH=/some/root/path/zorro
SIGPATH=/some/root/path/zorro-detached-sigs
./bin/gbuild --url litecoin=${BTCPATH},signature=${SIGPATH} ../litecoin/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gbuild --url zorro=${BTCPATH},signature=${SIGPATH} ../zorro/contrib/gitian-descriptors/gitian-win-signer.yml
```
Signing externally
@ -468,9 +468,9 @@ When you execute `gsign` you will get an error from GPG, which can be ignored. C
in `gitian.sigs` to your signing machine and do
```bash
gpg --detach-sign ${VERSION}-linux/${SIGNER}/litecoin-linux-build.assert
gpg --detach-sign ${VERSION}-win/${SIGNER}/litecoin-win-build.assert
gpg --detach-sign ${VERSION}-osx-unsigned/${SIGNER}/litecoin-osx-build.assert
gpg --detach-sign ${VERSION}-linux/${SIGNER}/zorro-linux-build.assert
gpg --detach-sign ${VERSION}-win/${SIGNER}/zorro-win-build.assert
gpg --detach-sign ${VERSION}-osx-unsigned/${SIGNER}/zorro-osx-build.assert
```
This will create the `.sig` files that can be committed together with the `.assert` files to assert your
@ -480,5 +480,5 @@ Uploading signatures
---------------------
After building and signing you can push your signatures (both the `.assert` and `.assert.sig` files) to the
[litecoin-project/gitian.sigs.ltc](https://github.com/litecoin-project/gitian.sigs.ltc/) repository, or if that's not possible create a pull
[zorro-project/gitian.sigs.ltc](https://github.com/zorro-project/gitian.sigs.ltc/) repository, or if that's not possible create a pull
request. You can also mail the files to thrasher (thrasher@addictionsofware.com) and he will commit them.

277
doc/guia-do-iniciante.md Normal file
View File

@ -0,0 +1,277 @@
[Português do Brasil](./guia-do-iniciante.md) | [English US](./beginners-guide.md)
# Zorro – Guia do Iniciante
Introdução:
=========================================================
Neste guia, apresentamos uma série de passos simples, que qualquer pessoa, mesmo sem experiência prévia, pode seguir para começar a utilizar sua criptomoeda.
Cada moeda criada pelo CryptoGera é disponibilizada automaticamente em um repositório público em https://git.cryptogera.com. Isso não só facilita o acesso ao código-fonte e aos programas de instalação, mas também é crucial para garantir que o código não tenha sido manipulado de maneira fraudulenta, validando assim a integridade e a legitimidade da moeda.
O repositório específico da moeda Zorro está localizado em https://git.cryptogera.com/cryptogera/zorro.
Neste local, você encontrará o código-fonte da moeda, junto com os binários - os programas compilados prontos para instalação e uso tanto no Windows quanto no Linux.
Abaixo, mostraremos como baixar e instalar esse software, além de oferecer uma introdução à mineração de suas primeiras moedas.
Baixe e instale a carteira da moeda
---------------------------------------------------------
Para baixar a carteira, acesse a aba "Releases" no repositório da moeda. No caso da moeda Zorro, o endereço para os "Releases" é:
[https://git.cryptogera.com/cryptogera/zorro/releases](https://git.cryptogera.com/cryptogera/zorro/releases)
Na página mencionada, você encontrará vários pacotes compactados com a extensão ".zip", contendo o software correspondente.
Para usuários do Windows, baixe o pacote "zorro-0.15.1-win64.zip". Se a versão de 64 bits não funcionar em seu sistema, tente a versão de 32 bits, chamada "zorro-0.15.1-win32.zip".
> Para usuários do Linux, há outro pacote disponível, chamado "zorro-0.15.1-linux-x86_64.zip", que requer um pouco mais de conhecimento para instalar. Se estiver usando o Ubuntu, você pode extrair esse arquivo na pasta "/" do seu computador para que os binários sejam colocados em "/usr/bin".
Ao abrir o pacote zip, você verá um programa executável com a extensão ".exe". Este é o instalador da carteira para Windows. Para iniciar a instalação, basta dar dois cliques nele. Uma janela semelhante a esta será exibida:
![Imagem: Iniciar instalação](first-steps/1_start_install.png)
A instalação é semelhante a qualquer outra instalação do Windows que você já tenha realizado. Basta seguir os passos até concluir a instalação. Ao final, a carteira da moeda "Zorro" estará instalada:
![Imagem: Concluir instalação](first-steps/2_finish_install.png)
Rodando o "Zorro Core" pela primeira vez
---------------------------------------------------------
Vamos abrir sua carteira recém-instalada. Para isso, basta clicar no ícone "Zorro Core" que aparece no menu do seu Windows.
Na primeira vez que você abrir sua carteira, verá uma janela semelhante a esta:
![Escolher Local de Armazenamento](first-steps/3_choose_storage_location.png)
Embora seja possível, não recomendamos que você altere o local (pasta) onde irá manter os dados da sua carteira e do blockchain. Clique no botão `OK` para utilizar o local padrão.
> Se você é um usuário iniciante, escolher um local diferente para armazenar os dados trará implicações que dificultarão, por exemplo, a questão de cópias de segurança. Mais adiante neste guia, explicaremos como restaurar uma cópia de segurança da sua carteira. No entanto, se você tiver mudado a pasta onde guarda os dados da carteira, as instruções não irão funcionar.
Em seguida, você verá uma janela semelhante a esta abaixo, que mostra que sua carteira está tentando baixar os dados do blockchain, ou seja, está tentando sincronizar a base de dados local dela com a base de dados da rede de dados da moeda Zorro.
![Sincronização da Carteira](first-steps/4_wallet_sync.png)
As moedas da família Bitcoin, como é o caso da moeda Zorro, funcionam em uma rede distribuída e descentralizada. Essa rede é composta por "nodes", que são as próprias carteiras interagindo umas com as outras. Esses "nodes" utilizam uma base de dados compartilhada entre todos eles, denominada "blockchain".
Sua carteira, toda vez que é aberta, tenta se conectar aos outros "nodes" da rede para sincronizar os dados do blockchain. Esta janela ficará aberta e parada, sem conseguir sincronizar, em duas situações:
- Quando não encontrar outro "node" na rede, seja por falha na conexão à internet ou por inexistência de outro "node" no ar no momento;
- Quando não houverem novas transações confirmadas, porque ninguém está "minerando" novos blocos.
Como sua moeda é nova, é normal que ela não tenha nada para sincronizar, por isso ela ficará desse jeito. A primeira coisa que você precisa fazer para "dar vida" ao blockchain da moeda "Zorro" é minerar o primeiro bloco. Veja no próximo passo como fazer isso.
Minere seu primeiro bloco
---------------------------------------------------------
Existem várias formas de minerar criptomoedas. As mais comuns são:
- Através de comandos na **janela de depuração** da carteira da moeda;
- Através da linha de comando, utilizando o cliente da própria moeda, no caso o "zorro-cli";
- Utilizando um software de mineração em conjunto com um servidor RPC;
- Utilizando um software de mineração conectado a um pool de mineração;
- Utilizando um equipamento de mineração conectado a um pool de mineração.
A primeira é a forma mais rápida e simples e, embora não seja eficiente para blockchains que já cresceram, funciona muito bem para uma criptomoeda que acabou de ser criada.
Para minerar seu primeiro bloco, abra a carteira "Zorro Core" que você instalou no Windows, acesse o menu "Ajuda", escolha "Janela de Depuração" e ative a aba "Console":
![Menu de Depuração](first-steps/5_menu_debug_window_option.png)
Na lacuna que aparece na parte inferior da aba de Console, digite `generate 1`:
![Comando Generate 1](first-steps/6_debug_window_generate_1.png)
Pressione ENTER e aguarde até que surja alguma resposta. O tempo de espera pela resposta depende da capacidade de processamento do seu computador. Você pode enviar o comando `generate 1` novamente antes de receber uma resposta, mas saiba que cada comando enviado aciona um processo adicional de mineração que exige mais recursos do seu processador e pode congelar sua carteira. Se isso acontecer, será necessário fechar e abrir o "Zorro Core" novamente.
Se você receber uma resposta como esta, com 2 colchetes vazios, significa que o bloco não foi gerado:
![Resposta Vazia](first-steps/7_generate_1_empty_answer.png)
Pode ser necessário repetir o comando `generate 1` algumas vezes até encontrar um bloco, o que é normal. Apenas certifique-se de não enviar o comando `generate 1` excessivamente para não congelar sua carteira. Abaixo, um exemplo de várias tentativas feitas:
![Várias Tentativas](first-steps/8_generate_1_several_requests.png)
E finalmente, algumas respostas com sucesso, após várias tentativas do comando `generate 1`. Observe que, quando um bloco é minerado com sucesso, aparece uma sequência de letras e números entre colchetes:
![Sucesso na Mineração](first-steps/9_generate_1_success.png)
Os blocos que você acabou de minerar aparecem na sua carteira, cada um como uma recompensa de 50 moedas:
![Recompensa do Bloco](first-steps/10_wallet_four_block_rewards.png)
Mas calma, as moedas da recompensa ainda não são suas. Cada novo bloco minerado precisa receber 101 confirmações antes de ser pago. Para isso, mais 101 blocos precisam ser minerados no blockchain, por você ou por outras pessoas. Quando isso acontecer, essas moedas ficarão automaticamente disponíveis na sua carteira.
> No Linux, os passos seriam, primeiramente, iniciar o zorrod em modo daemon com o comando `zorrod –daemon` e, em seguida, usar o cliente para gerar o bloco com o comando `zorro-cli generate 1`.
Proteja sua carteira com uma senha
---------------------------------------------------------
Uma carteira recém-instalada não possui senha, o que coloca suas moedas em risco caso outras pessoas tenham acesso ao seu computador.
Para criar uma nova senha, você precisa acessar o menu "Definições" e escolher "Criptografar Carteira":
![Menu Criptografar Carteira](first-steps/11_encrypt_wallet_menu.png)
Em seguida, informe a nova senha (passphrase) para proteger sua carteira. A mesma senha precisa ser digitada nas duas lacunas. Recomenda-se que a senha seja composta por pelo menos 10 caracteres aleatórios ou oito ou mais palavras. Tome nota da senha informada e clique em `OK` para prosseguir:
![Informe a Senha](first-steps/12_encrypt_wallet_passphrase.png)
Depois, você verá este importante aviso, que alerta que caso você esqueça sua senha, TODAS AS MOEDAS DA SUA CARTEIRA serão perdidas. Se deseja prosseguir instalando a proteção da sua carteira, responda "Sim":
![Aviso Importante](first-steps/13_encrypt_wallet_warning.png)
Finalmente, surge um alerta de que, mesmo criptografada, sua carteira não é invulnerável ou à prova de malware caso seu computador seja infectado. Também avisa que, caso você tenha feito algum backup antes de criptografar sua carteira, ele estará desprotegido e, por isso, deve ser substituído por um novo backup:
![Alerta do Processo](first-steps/14_encrypt_wallet_process_alert.png)
Clique no botão `OK` e o processo de criptografia irá começar. Não interrompa o processo, mesmo se ele parecer travado, como mostrado abaixo:
![Processo Congelado](first-steps/15_frozen_process.png)
Essa janela em branco irá desaparecer sozinha assim que o processo terminar.
Pronto! Sua carteira está criptografada e, a partir de agora, sempre que você for enviar moedas, precisará informar essa senha (passphrase).
> Jamais esqueça a senha da sua carteira. Sem ela, você nunca mais terá acesso às moedas da sua carteira.
No futuro, como trocar a senha da carteira?
---------------------------------------------------------
Se a carteira estiver criptografada, no menu "Definições", você verá que a opção "Criptografar Carteira" aparece desabilitada e a opção "Mudar frase de segurança" habilitada. Use essa opção se algum dia desejar mudar a senha da sua carteira.
![Mudar Frase de Segurança](first-steps/16_change_passphrase.png)
Como fazer uma cópia de segurança da sua carteira
---------------------------------------------------------
No menu suspenso que aparece ao clicar em "File", escolha a opção "Backup Wallet..." (Fazer backup da carteira).
![Backup da Carteira](first-steps/17_backup_wallet.png)
Uma janela de diálogo será aberta para você selecionar o local onde deseja salvar o arquivo de backup. Escolha uma localização segura no seu computador ou em um dispositivo de armazenamento externo.
![Diálogo de Backup](first-steps/18_backup_dialog.png)
Dê um nome significativo ao arquivo de backup, por exemplo, "wallet_backup.dat". Clique em "Salvar" para concluir o processo.
Certifique-se de que o arquivo de backup tenha sido salvo com sucesso no local desejado.
**IMPORTANTE!** É crucial armazenar seu arquivo de backup em um local seguro e, de preferência, criptografado, como uma unidade externa ou serviço de armazenamento em nuvem confiável.
Ao seguir esses passos, você terá feito um backup da sua carteira Zorro Core usando a opção "File -> Backup Wallet" no Windows. Certifique-se de fazer novos backups regularmente para garantir a segurança das suas moedas.
Como restaurar uma cópia de segurança da sua carteira
---------------------------------------------------------
> **ALERTA!** Jamais restaure backups antigos em cima de carteiras atuais. Ao restaurar um backup da sua carteira, qualquer transação ou saldo feito após este backup será perdida, pois o backup substituirá o estado atual da sua carteira pelo estado no momento em que o backup foi feito. Portanto, é importante fazer backups regularmente e manter uma boa prática de segurança para proteger suas moedas.
### Passo 1: Feche o "Zorro Core"
Se o "Zorro Core" estiver aberto, feche-o completamente antes de prosseguir com a restauração do backup.
### Passo 2: Localize o arquivo de backup
Certifique-se de ter acesso ao arquivo de backup da sua carteira. Isso geralmente será um arquivo com extensão ".dat" que você salvou anteriormente.
### Passo 3: Acesse a pasta de dados do "Zorro Core"
Abra o Explorador de Arquivos do Windows.
Navegue até `%appdata%\zorro`. Você pode simplesmente copiar e colar `%appdata%\zorro` na barra de endereços do Explorador de Arquivos e pressionar Enter para acessar essa pasta rapidamente.
### Passo 4: Faça backup da sua carteira existente (opcional)
Antes de prosseguir com a restauração, é uma boa prática fazer backup da sua carteira existente, caso haja alguma informação importante que você não queira perder.
### Passo 5: Substitua o arquivo de carteira existente pelo backup
No diretório `%appdata%\zorro`, encontre o arquivo de carteira existente, que geralmente tem o nome "wallet.dat".
Renomeie "wallet.dat" para "wallet-previous.dat" ou copie este arquivo para outra pasta como precaução.
Copie o arquivo de backup da sua carteira para o diretório `%appdata%\zorro` e ajuste o nome dele para "wallet.dat".
### Passo 6: Inicie o "Zorro Core"
Após substituir o arquivo de carteira, inicie o "Zorro Core" novamente.
### Passo 7: Verifique se a restauração foi bem-sucedida
Assim que o "Zorro Core" estiver aberto, verifique se sua carteira foi restaurada corretamente. Verifique o saldo e as transações para garantir que tudo esteja como esperado.
Enviando e recebendo moedas
---------------------------------------------------------
O "Zorro Core" oferece uma ampla gama de recursos para enviar e receber moedas de forma segura. Siga este passo a passo para aprender como utilizar essas funcionalidades:
### Enviando Moedas:
1. **Abra o "Zorro Core":**
- Inicie o aplicativo "Zorro Core" em seu computador.
2. **Acesse sua Carteira:**
- Após abrir o "Zorro Core", aguarde até que sua carteira seja carregada. Você precisará inserir sua senha, se houver, para desbloquear sua carteira.
3. **Selecione "Enviar":**
- No menu principal, clique em "Enviar" ou encontre a opção de envio na barra de navegação.
4. **Preencha os Detalhes da Transação:**
- Insira o endereço "Zorro" do destinatário no campo designado.
- Especifique o valor que deseja enviar em Zorro.
- Adicione uma taxa de transação, se desejar. Uma taxa mais alta geralmente resulta em uma confirmação mais rápida da transação.
5. **Revisão e Confirmação:**
- Antes de enviar a transação, verifique cuidadosamente os detalhes, como o endereço de destino e o valor.
- Confirme a transação e aguarde a confirmação na blockchain.
### Recebendo Moedas:
1. **Obtenha seu Endereço "Zorro":**
- No "Zorro Core", vá para a seção "Receber" ou encontre o endereço "Zorro" em sua carteira.
- Copie o endereço "Zorro" fornecido.
2. **Compartilhe seu Endereço:**
- Cole o endereço "Zorro" em um email, mensagem ou plataforma de pagamento para o remetente enviar as moedas para você.
3. **Verifique o Recebimento:**
- Aguarde até que o remetente envie as moedas para o seu endereço.
- Assim que as moedas forem recebidas, elas aparecerão em sua carteira "Zorro Core".
4. **Confirmação na Blockchain:**
- A transação será registrada na blockchain e, após algumas confirmações, as moedas serão consideradas totalmente recebidas e disponíveis para uso.
Lembre-se sempre de manter sua chave privada segura e fazer backup regularmente de sua carteira "Zorro Core" para garantir a segurança de suas moedas.
Recomendações finais
---------------------------------------------------------
- **Registre um domínio internet para sua moeda:**
- Garanta uma presença online sólida registrando um domínio dedicado para sua moeda. Isso facilita a criação de um site oficial e fornece um ponto central para informações e comunicação com a comunidade.
- **Registre a marca da sua moeda:**
- Proteja a identidade e reputação da sua moeda registrando sua marca. Isso ajuda a evitar possíveis conflitos legais e promove a confiança entre os usuários e investidores.
- **Divulgue sua moeda em todos os locais possíveis:**
- Utilize mídias sociais, fóruns relacionados, blogs e outros canais para divulgar sua moeda. Quanto mais pessoas conhecerem sua moeda, maior será sua adoção e valorização.
- **Minere e incentive a mineração o máximo que puder:**
- A mineração é essencial para a segurança e descentralização da sua moeda. Incentive os mineradores oferecendo recompensas justas e promovendo a mineração entre sua comunidade.
- **Coloque um blockchain explorer no ar:**
- Um explorador de blockchain permite que os usuários visualizem transações, saldos de contas e outras informações importantes sobre sua moeda. Disponibilize um explorador para aumentar a transparência e confiança na sua moeda.
- **Desenvolva um APP carteira da sua moeda:**
- Facilite o acesso e a utilização da sua moeda desenvolvendo uma carteira móvel para dispositivos iOS e Android. Isso permite que os usuários gerenciem suas moedas de forma conveniente e segura.
- **Inclua sua moeda em mining pools:**
- Mining pools são grupos de mineradores que combinam seu poder de processamento para aumentar as chances de encontrar blocos e receber recompensas. Liste sua moeda em diferentes pools para atrair mais mineradores.
- **Liste sua moeda em agregadores e exchanges:**
- Torne sua moeda acessível para compra, venda e negociação listando-a em plataformas de troca de criptomoedas e agregadores de preços. Isso aumenta a liquidez e a visibilidade da sua moeda no mercado.
- **Pronto para uma ICO?:**
- Se estiver planejando uma oferta inicial de moedas (ICO), certifique-se de seguir todas as regulamentações e requisitos legais. Prepare um whitepaper detalhado e estabeleça um cronograma claro para sua ICO.

94
doc/litecoin-release-notes/release-notes-0.10.2.2.md
View File

@ -1,94 +0,0 @@
Litecoin Core version 0.10.2.2 is now available from:
<https://download.litecoin.org/litecoin-0.10.2.2/>
This is a new major 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/litecoin-project/litecoin/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/Litecoin-Qt (on Mac) or
litecoind/litecoin-qt (on Linux).
Downgrade warning
------------------
Because release 0.10+ 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 Litecoin 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.
Litecoin 0.10.2.2 Change log
============================
This release is based upon Bitcoin Core v0.10.2. Their upstream changelog applies to us and
is included in as separate release-notes. This section describes the Litecoin-specific differences.
Protocol:
- Scrypt Proof-of-Work instead of sha256d, however block hashes are sha256d for performance reasons.
- Litecoin TCP port 9333 (instead of 8333)
- RPC TCP port 9332 (instead of 8332)
- Testnet TCP port 19333 (instead of 18333)
- Testnet RPC TCP port 19332 (instead of 18332)
- 84 million coin limit (instead of 21 million)
- Magic 0xfbc0b6db (instead of 0xf9beb4d9)
- Target Block Time 2.5 minutes (instead of 10 minutes)
- Target Timespan 3.5 days (instead of two weeks)
- bnProofOfWorkLimit = >> 20 (instead of >> 32)
- See 9a980612005adffdeb2a17ca7a09fe126dd45e0e for Genesis Parameters
- zeitgeist2 protection: b1b31d15cc720a1c186431b21ecc9d1a9062bcb6 Slightly different way to calculate difficulty changes.
- Litecoin Core v0.10.2.2 is protocol version 70003 (instead of 70002)
Relay:
- Litecoin Core rounds transaction size up to the nearest 1000 bytes before calculating fees. This size rounding behavior is to mimic fee calculation of Litecoin v0.6 and v0.8.
- Bitcoin's IsDust() is disabled in favor of Litecoin's fee-based dust penalty.
- Fee-based Dust Penalty: For each transaction output smaller than DUST_THRESHOLD (currently 0.001 LTC) the default relay/mining policy will expect an additional 1000 bytes of fee. Otherwise the transaction will be rejected from relay/mining. Such transactions are also disqualified from the free/high-priority transaction rule.
- Miners and relays can adjust the expected fee per-KB with the -minrelaytxfee parameter.
Wallet:
- Coins smaller than 0.00001 LTC are by default ignored by the wallet. Use the -mininput parameter if you want to see smaller coins.
Notable changes since Litecoin v0.8
===================================
- The Block data and indexes of v0.10 are incompatible with v0.8 clients. You can upgrade from v0.8 but you downgrading is not possible. For this reason you may want to make a backup copy of your Data Directory.
- litecoind no longer sends RPC commands. You must use the separate litecoin-cli command line utility.
- Watch-Only addresses are now possible.
Credits
=======
Thanks to everyone who directly contributed to this release:
- Charles Lee
- pooler
- Gitju
- Adrian Gallagher
- Anton Yemelyanov
- Martin Smith
- Warren Togami

123
doc/litecoin-release-notes/release-notes-0.10.4.md
View File

@ -1,123 +0,0 @@
Litecoin Core version 0.10.4.0 is now available from:
<https://download.litecoin.org/litecoin-0.10.4.0/>
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/litecoin-project/litecoin/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/Litecoin-Qt (on Mac) or
litecoind/litecoin-qt (on Linux).
Downgrade warning
------------------
Because release 0.10+ 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 Litecoin 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 since 0.10.3
============================
BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode
--------------------------------------------------------
This release includes several changes related to the [BIP65][] 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.
**Notice to miners:** Litecoin 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 v0.4.3 or any version from v0.5.2 onward.
- If you are solo mining, this will affect you the moment you upgrade
Litecoin 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.
[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
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 Litecoin 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.10.4 Change log
=================
This release is based upon Bitcoin Core v0.10.4. Their upstream changelog applies to us and
is included in as separate release-notes, see: [Release Notes](release-notes.md).
This section describes the Litecoin-specific differences.
- Added BIP65 CHECKLOCKTIMEVERIFY softfork.
- Increased OP_RETURN relay size to 80 bytes.
Credits
=======
Thanks to everyone who directly contributed to this release:
- Charles Lee
- pooler
- Adrian Gallagher
- Anton Yemelyanov
- Warren Togami
- BtcDrak

993
doc/litecoin-release-notes/release-notes-0.13.2.md
View File

@ -1,993 +0,0 @@
Litecoin Core version 0.13.2 is now available from:
<https://download.litecoin.org/litecoin-0.13.2.1/>
This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations.
It is recommended to upgrade to this version.
Please report bugs using the issue tracker at github:
<https://github.com/litecoin-project/litecoin/issues>
Compatibility
==============
Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a litecoin
wallet on a XP machine is irresponsible at least.
In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.
We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.
No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.
From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.
Notable changes
===============
Signature validation using libsecp256k1
---------------------------------------
ECDSA signatures inside Litecoin transactions now use validation using
[libsecp256k1](https://github.com/bitcoin-core/secp256k1) instead of OpenSSL.
Depending on the platform, this means a significant speedup for raw signature
validation speed. The advantage is largest on x86_64, where validation is over
five times faster. In practice, this translates to a raw reindexing and new
block validation times that are less than half of what it was before.
Libsecp256k1 has undergone very extensive testing and validation.
A side effect of this change is that libconsensus no longer depends on OpenSSL.
Reduce upload traffic
---------------------
A major part of the outbound traffic is caused by serving historic blocks to
other nodes in initial block download state.
It is now possible to reduce the total upload traffic via the `-maxuploadtarget`
parameter. This is *not* a hard limit but a threshold to minimize the outbound
traffic. When the limit is about to be reached, the uploaded data is cut by not
serving historic blocks (blocks older than one week).
Moreover, any SPV peer is disconnected when they request a filtered block.
This option can be specified in MiB per day and is turned off by default
(`-maxuploadtarget=0`).
The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day.
Whitelisted peers will never be disconnected, although their traffic counts for
calculating the target.
A more detailed documentation about keeping traffic low can be found in
[/doc/reduce-traffic.md](/doc/reduce-traffic.md).
Direct headers announcement (BIP 130)
-------------------------------------
Between compatible peers, [BIP 130]
(https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki)
direct headers announcement is used. This means that blocks are advertised by
announcing their headers directly, instead of just announcing the hash. In a
reorganization, all new headers are sent, instead of just the new tip. This
can often prevent an extra roundtrip before the actual block is downloaded.
Memory pool limiting
--------------------
Previous versions of Litecoin Core had their mempool limited by checking
a transaction's fees against the node's minimum relay fee. There was no
upper bound on the size of the mempool and attackers could send a large
number of transactions paying just slighly more than the default minimum
relay fee to crash nodes with relatively low RAM. A temporary workaround
for previous versions of Litecoin Core was to raise the default minimum
relay fee.
Litecoin Core 0.13.2 will have a strict maximum size on the mempool. The
default value is 300 MB and can be configured with the `-maxmempool`
parameter. Whenever a transaction would cause the mempool to exceed
its maximum size, the transaction that (along with in-mempool descendants) has
the lowest total feerate (as a package) will be evicted and the node's effective
minimum relay feerate will be increased to match this feerate plus the initial
minimum relay feerate. The initial minimum relay feerate is set to
1000 satoshis per kB.
Litecoin Core 0.13.2 also introduces new default policy limits on the length and
size of unconfirmed transaction chains that are allowed in the mempool
(generally limiting the length of unconfirmed chains to 25 transactions, with a
total size of 101 KB). These limits can be overriden using command line
arguments; see the extended help (`--help -help-debug`) for more information.
RPC: Random-cookie RPC authentication
-------------------------------------
When no `-rpcpassword` is specified, the daemon now uses a special 'cookie'
file for authentication. This file is generated with random content when the
daemon starts, and deleted when it exits. Its contents are used as
authentication token. Read access to this file controls who can access through
RPC. By default it is stored in the data directory but its location can be
overridden with the option `-rpccookiefile`.
This is similar to Tor's CookieAuthentication: see
https://www.torproject.org/docs/tor-manual.html.en
This allows running litecoind without having to do any manual configuration.
Relay: Any sequence of pushdatas in OP_RETURN outputs now allowed
-----------------------------------------------------------------
Previously OP_RETURN outputs with a payload were only relayed and mined if they
had a single pushdata. This restriction has been lifted to allow any
combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after
the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire
serialized scriptPubKey, 83 bytes by default. (the previous 80 byte default plus
three bytes overhead)
Relay: New and only new blocks relayed when pruning
---------------------------------------------------
When running in pruned mode, the client will now relay new blocks. When
responding to the `getblocks` message, only hashes of blocks that are on disk
and are likely to remain there for some reasonable time window (1 hour) will be
returned (previously all relevant hashes were returned).
Relay and Mining: Priority transactions
---------------------------------------
Litecoin Core has a heuristic 'priority' based on coin value and age. This
calculation is used for relaying of transactions which do not pay the
minimum relay fee, and can be used as an alternative way of sorting
transactions for mined blocks. Litecoin Core will relay transactions with
insufficient fees depending on the setting of `-limitfreerelay=<r>` (default:
`r=15` kB per minute) and `-blockprioritysize=<s>`.
In Bitcoin Core 0.12, when mempool limit has been reached a higher minimum
relay fee takes effect to limit memory usage. Transactions which do not meet
this higher effective minimum relay fee will not be relayed or mined even if
they rank highly according to the priority heuristic.
The mining of transactions based on their priority is also now disabled by
default. To re-enable it, simply set `-blockprioritysize=<n>` where is the size
in bytes of your blocks to reserve for these transactions. The old default was
50k, so to retain approximately the same policy, you would set
`-blockprioritysize=50000`.
Additionally, as a result of computational simplifications, the priority value
used for transactions received with unconfirmed inputs is lower than in prior
versions due to avoiding recomputing the amounts as input transactions confirm.
External miner policy set via the `prioritisetransaction` RPC to rank
transactions already in the mempool continues to work as it has previously.
Note, however, that if mining priority transactions is left disabled, the
priority delta will be ignored and only the fee metric will be effective.
This internal automatic prioritization handling is being considered for removal
entirely in Litecoin Core 0.13, and it is at this time undecided whether the
more accurate priority calculation for chained unconfirmed transactions will be
restored. Community direction on this topic is particularly requested to help
set project priorities.
Automatically use Tor hidden services
-------------------------------------
Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
API, to create and destroy 'ephemeral' hidden services programmatically.
Litecoin Core has been updated to make use of this.
This means that if Tor is running (and proper authorization is available),
Litecoin Core automatically creates a hidden service to listen on, without
manual configuration. Litecoin Core will also use Tor automatically to connect
to other .onion nodes if the control socket can be successfully opened. This
will positively affect the number of available .onion nodes and their usage.
This new feature is enabled by default if Litecoin Core is listening, and
a connection to Tor can be made. It can be configured with the `-listenonion`,
`-torcontrol` and `-torpassword` settings. To show verbose debugging
information, pass `-debug=tor`.
Notifications through ZMQ
-------------------------
Litecoind can now (optionally) asynchronously notify clients through a
ZMQ-based PUB socket of the arrival of new transactions and blocks.
This feature requires installation of the ZMQ C API library 4.x and
configuring its use through the command line or configuration file.
Please see [docs/zmq.md](/doc/zmq.md) for details of operation.
Wallet: Transaction fees
------------------------
Various improvements have been made to how the wallet calculates
transaction fees.
Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>`
(or `settxfee <n>` rpc during runtime). A value of `n=0` signals Litecoin
Core to use floating fees. By default, Litecoin Core will use floating
fees.
Based on past transaction data, floating fees approximate the fees
required to get into the `m`th block from now. This is configurable
with `-txconfirmtarget=<m>` (default: `2`).
Sometimes, it is not possible to give good estimates, or an estimate
at all. Therefore, a fallback value can be set with `-fallbackfee=<f>`
(default: `0.0002` LTC/kB).
At all times, Litecoin Core will cap fees at `-maxtxfee=<x>` (default:
0.10) LTC.
Furthermore, Litecoin Core will never create transactions paying less than
the current minimum relay fee.
Finally, a user can set the minimum fee rate for all transactions with
`-mintxfee=<i>`, which defaults to 1000 satoshis per kB.
Wallet: Negative confirmations and conflict detection
-----------------------------------------------------
The wallet will now report a negative number for confirmations that indicates
how deep in the block chain the conflict is found. For example, if a transaction
A has 5 confirmations and spends the same input as a wallet transaction B, B
will be reported as having -5 confirmations. If another wallet transaction C
spends an output from B, it will also be reported as having -5 confirmations.
To detect conflicts with historical transactions in the chain a one-time
`-rescan` may be needed.
Unlike earlier versions, unconfirmed but non-conflicting transactions will never
get a negative confirmation count. They are not treated as spendable unless
they're coming from ourself (change) and accepted into our local mempool,
however. The new "trusted" field in the `listtransactions` RPC output
indicates whether outputs of an unconfirmed transaction are considered
spendable.
Wallet: Merkle branches removed
-------------------------------
Previously, every wallet transaction stored a Merkle branch to prove its
presence in blocks. This wasn't being used for more than an expensive
sanity check. Since 0.13.2, these are no longer stored. When loading a
0.13.2 wallet into an older version, it will automatically rescan to avoid
failed checks.
Wallet: Pruning
---------------
With 0.13.2 it is possible to use wallet functionality in pruned mode.
This can reduce the disk usage from currently around 6 GB to
around 0.2 GB.
However, rescans as well as the RPCs `importwallet`, `importaddress`,
`importprivkey` are disabled.
To enable block pruning set `prune=<N>` on the command line or in
`litecoin.conf`, where `N` is the number of MiB to allot for
raw block & undo data.
A value of 0 disables pruning. The minimal value above 0 is 550. Your
wallet is as secure with high values as it is with low ones. Higher
values merely ensure that your node will not shut down upon blockchain
reorganizations of more than 2 days - which are unlikely to happen in
practice. In future releases, a higher value may also help the network
as a whole: stored blocks could be served to other nodes.
For further information about pruning, you may also consult the [release
notes of Bitcoin Core v0.11.0](https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning).
`NODE_BLOOM` service bit
------------------------
Support for the `NODE_BLOOM` service bit, as described in [BIP
111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki), has been
added to the P2P protocol code.
BIP 111 defines a service bit to allow peers to advertise that they support
bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol
version to allow peers to identify old nodes which allow bloom filtering of the
connection despite lacking the new service bit.
In this version, it is only enforced for peers that send protocol versions
`>=70011`. For the next major version it is planned that this restriction will be
removed. It is recommended to update SPV clients to check for the `NODE_BLOOM`
service bit for nodes that report versions newer than 70011.
Option parsing behavior
-----------------------
Command line options are now parsed strictly in the order in which they are
specified. It used to be the case that `-X -noX` ends up, unintuitively, with X
set, as `-X` had precedence over `-noX`. This is no longer the case. Like for
other software, the last specified value for an option will hold.
RPC: Low-level API changes
--------------------------
- Monetary amounts can be provided as strings. This means that for example the
argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an
advantage if a JSON library insists on using a lossy floating point type for
numbers, which would be dangerous for monetary amounts.
* The `asm` property of each scriptSig now contains the decoded signature hash
type for each signature that provides a valid defined hash type.
* OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)
The following items contain assembly representations of scriptSig signatures
and are affected by this change:
- RPC `getrawtransaction`
- RPC `decoderawtransaction`
- RPC `decodescript`
- REST `/rest/tx/` (JSON format)
- REST `/rest/block/` (JSON format when including extended tx details)
- `litecoin-tx -json`
For example, the `scriptSig.asm` property of a transaction input that
previously showed an assembly representation of:
304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 400000 OP_NOP2
now shows as:
304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] 400000 OP_CHECKLOCKTIMEVERIFY
Note that the output of the RPC `decodescript` did not change because it is
configured specifically to process scriptPubKey and not scriptSig scripts.
RPC: SSL support dropped
------------------------
SSL support for RPC, previously enabled by the option `rpcssl` has been dropped
from both the client and the server. This was done in preparation for removing
the dependency on OpenSSL for the daemon completely.
Trying to use `rpcssl` will result in an error:
Error: SSL mode for RPC (-rpcssl) is no longer supported.
If you are one of the few people that relies on this feature, a flexible
migration path is to use `stunnel`. This is an utility that can tunnel
arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with:
sudo apt-get install stunnel4
Then, to tunnel a SSL connection on 29332 to a RPC server bound on localhost on port 19334 do:
stunnel -d 29332 -r 127.0.0.1:19334 -p stunnel.pem -P ''
It can also be set up system-wide in inetd style.
Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution
would allow the use of different authentication, loadbalancing, on-the-fly compression and
caching. A sample config for apache2 could look like:
Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
<Location /litecoinrpc>
ProxyPass http://127.0.0.1:9332/
ProxyPassReverse http://127.0.0.1:9332/
# optional enable digest auth
# AuthType Digest
# ...
# optional bypass litecoind rpc basic auth
# RequestHeader set Authorization "Basic <hash>"
# get the <hash> from the shell with: base64 <<< litecoinrpc:<password>
</Location>
# Or, balance the load:
# ProxyPass / balancer://balancer_cluster_name
</VirtualHost>
Other P2P Changes
-----------------
The list of banned peers is now stored on disk rather than in memory.
Restarting litecoind will no longer clear out the list of banned peers; instead
a new RPC call (`clearbanned`) can be used to manually clear the list. The new
`setban` RPC call can also be used to manually ban or unban a peer.
Database cache memory increased
--------------------------------
As a result of growth of the UTXO set, performance with the prior default
database cache of 100 MiB has suffered.
For this reason the default was changed to 300 MiB in this release.
For nodes on low-memory systems, the database cache can be changed back to
100 MiB (or to another value) by either:
- Adding `dbcache=100` in litecoin.conf
- Changing it in the GUI under `Options → Size of database cache`
Note that the database cache setting has the most performance impact
during initial sync of a node, and when catching up after downtime.
litecoin-cli: arguments privacy
------------------------------
The RPC command line client gained a new argument, `-stdin`
to read extra arguments from standard input, one per line until EOF/Ctrl-D.
For example:
$ src/litecoin-cli -stdin walletpassphrase
mysecretcode
120
..... press Ctrl-D here to end input
$
It is recommended to use this for sensitive information such as wallet
passphrases, as command-line arguments can usually be read from the process
table by any user on the system.
C++11 and Python 3
------------------
Various code modernizations have been done. The Litecoin Core code base has
started using C++11. This means that a C++11-capable compiler is now needed for
building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher.
When cross-compiling for a target that doesn't have C++11 libraries, configure with
`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`.
For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now
required.
Linux ARM builds
----------------
Due to popular request, Linux ARM builds have been added to the uploaded
executables.
The following extra files can be found in the download directory or torrent:
- `litecoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most
common 32-bit ARM architecture.
- `litecoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most
common 64-bit ARM architecture.
ARM builds are still experimental. If you have problems on a certain device or
Linux distribution combination please report them on the bug tracker, it may be
possible to resolve them.
Note that Android is not considered ARM Linux in this context. The executables
are not expected to work out of the box on Android.
BIP68 soft fork to enforce sequence locks for relative locktime
---------------------------------------------------------------
[BIP68][] introduces relative lock-time consensus-enforced semantics of
the sequence number field to enable a signed transaction input to remain
invalid for a defined period of time after confirmation of its corresponding
outpoint.
For more information about the implementation, see
<https://github.com/bitcoin/bitcoin/pull/7184>
BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY
--------------------------------------------------
[BIP112][] redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV)
for a new opcode in the Litecoin scripting system that in combination with
[BIP68][] allows execution pathways of a script to be restricted based
on the age of the output being spent.
For more information about the implementation, see
<https://github.com/bitcoin/bitcoin/pull/7524>
BIP113 locktime enforcement soft fork
-------------------------------------
This release seeks to make mempool-only locktime enforcement using GetMedianTimePast()
a consensus rule.
Litecoin 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][] specifies a soft fork 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 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.
For more information about the implementation, see
<https://github.com/bitcoin/bitcoin/pull/6566>
Compact Block support (BIP 152)
-------------------------------
Support for block relay using the Compact Blocks protocol has been implemented
in PR 8068.
The primary goal is reducing the bandwidth spikes at relay time, though in many
cases it also reduces propagation delay. It is automatically enabled between
compatible peers.
[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)
As a side-effect, ordinary non-mining nodes will download and upload blocks
faster if those blocks were produced by miners using similar transaction
filtering policies. This means that a miner who produces a block with many
transactions discouraged by your node will be relayed slower than one with
only transactions already in your memory pool. The overall effect of such
relay differences on the network may result in blocks which include widely-
discouraged transactions losing a stale block race, and therefore miners may
wish to configure their node to take common relay policies into consideration.
Hierarchical Deterministic Key Generation
-----------------------------------------
Newly created wallets will use hierarchical deterministic key generation
according to BIP32 (keypath m/0'/0'/k').
Existing wallets will still use traditional key generation.
Backups of HD wallets, regardless of when they have been created, can
therefore be used to re-generate all possible private keys, even the
ones which haven't already been generated during the time of the backup.
**Attention:** Encrypting the wallet will create a new seed which requires
a new backup!
Wallet dumps (created using the `dumpwallet` RPC) will contain the deterministic
seed. This is expected to allow future versions to import the seed and all
associated funds, but this is not yet implemented.
HD key generation for new wallets can be disabled by `-usehd=0`. Keep in
mind that this flag only has affect on newly created wallets.
You can't disable HD key generation once you have created a HD wallet.
There is no distinction between internal (change) and external keys.
HD wallets are incompatible with older versions of Litecoin Core.
[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
Mining transaction selection ("Child Pays For Parent")
------------------------------------------------------
The mining transaction selection algorithm has been replaced with an algorithm
that selects transactions based on their feerate inclusive of unconfirmed
ancestor transactions. This means that a low-fee transaction can become more
likely to be selected if a high-fee transaction that spends its outputs is
relayed.
With this change, the `-blockminsize` command line option has been removed.
The command line option `-blockmaxsize` remains an option to specify the
maximum number of serialized bytes in a generated block. In addition, the new
command line option `-blockmaxweight` has been added, which specifies the
maximum "block weight" of a generated block, as defined by [BIP 141 (Segregated
Witness)] (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).
In preparation for Segregated Witness, the mining algorithm has been modified
to optimize transaction selection for a given block weight, rather than a given
number of serialized bytes in a block. In this release, transaction selection
is unaffected by this distinction (as BIP 141 activation is not supported on
mainnet in this release, see above), but in future releases and after BIP 141
activation, these calculations would be expected to differ.
For optimal runtime performance, miners using this release should specify
`-blockmaxweight` on the command line, and not specify `-blockmaxsize`.
Additionally (or only) specifying `-blockmaxsize`, or relying on default
settings for both, may result in performance degradation, as the logic to
support `-blockmaxsize` performs additional computation to ensure that
constraint is met. (Note that for mainnet, in this release, the equivalent
parameter for `-blockmaxweight` would be four times the desired
`-blockmaxsize`. See [BIP 141]
(https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) for additional
details.)
In the future, the `-blockmaxsize` option may be removed, as block creation is
no longer optimized for this metric. Feedback is requested on whether to
deprecate or keep this command line option in future releases.
Reindexing changes
------------------
In earlier versions, reindexing did validation while reading through the block
files on disk. These two have now been split up, so that all blocks are known
before validation starts. This was necessary to make certain optimizations that
are available during normal synchronizations also available during reindexing.
The two phases are distinct in the Litecoin-Qt GUI. During the first one,
"Reindexing blocks on disk" is shown. During the second (slower) one,
"Processing blocks on disk" is shown.
It is possible to only redo validation now, without rebuilding the block index,
using the command line option `-reindex-chainstate` (in addition to
`-reindex` which does both). This new option is useful when the blocks on disk
are assumed to be fine, but the chainstate is still corrupted. It is also
useful for benchmarks.
Removal of internal miner
--------------------------
As CPU mining has been useless for a long time, the internal miner has been
removed in this release, and replaced with a simpler implementation for the
test framework.
The overall result of this is that `setgenerate` RPC call has been removed, as
well as the `-gen` and `-genproclimit` command-line options.
For testing, the `generate` call can still be used to mine a block, and a new
RPC call `generatetoaddress` has been added to mine to a specific address. This
works with wallet disabled.
New bytespersigop implementation
--------------------------------
The former implementation of the bytespersigop filter accidentally broke bare
multisig (which is meant to be controlled by the `permitbaremultisig` option),
since the consensus protocol always counts these older transaction forms as 20
sigops for backwards compatibility. Simply fixing this bug by counting more
accurately would have reintroduced a vulnerability. It has therefore been
replaced with a new implementation that rather than filter such transactions,
instead treats them (for fee purposes only) as if they were in fact the size
of a transaction actually using all 20 sigops.
Low-level P2P changes
----------------------
- The optional new p2p message "feefilter" is implemented and the protocol
version is bumped to 70013. Upon receiving a feefilter message from a peer,
a node will not send invs for any transactions which do not meet the filter
feerate. [BIP 133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki)
- The P2P alert system has been removed in PR #7692 and the `alert` P2P message
is no longer supported.
- The transaction relay mechanism used to relay one quarter of all transactions
instantly, while queueing up the rest and sending them out in batch. As
this resulted in chains of dependent transactions being reordered, it
systematically hurt transaction relay. The relay code was redesigned in PRs
\#7840 and #8082, and now always batches transactions announcements while also
sorting them according to dependency order. This significantly reduces orphan
transactions. To compensate for the removal of instant relay, the frequency of
batch sending was doubled for outgoing peers.
- Since PR #7840 the BIP35 `mempool` command is also subject to batch processing.
Also the `mempool` message is no longer handled for non-whitelisted peers when
`NODE_BLOOM` is disabled through `-peerbloomfilters=0`.
- The maximum size of orphan transactions that are kept in memory until their
ancestors arrive has been raised in PR #8179 from 5000 to 99999 bytes. They
are now also removed from memory when they are included in a block, conflict
with a block, and time out after 20 minutes.
- We respond at most once to a getaddr request during the lifetime of a
connection since PR #7856.
- Connections to peers who have recently been the first one to give us a valid
new block or transaction are protected from disconnections since PR #8084.
Low-level RPC changes
----------------------
- RPC calls have been added to output detailed statistics for individual mempool
entries, as well as to calculate the in-mempool ancestors or descendants of a
transaction: see `getmempoolentry`, `getmempoolancestors`, `getmempooldescendants`.
- `gettxoutsetinfo` UTXO hash (`hash_serialized`) has changed. There was a divergence between
32-bit and 64-bit platforms, and the txids were missing in the hashed data. This has been
fixed, but this means that the output will be different than from previous versions.
- Full UTF-8 support in the RPC API. Non-ASCII characters in, for example,
wallet labels have always been malformed because they weren't taken into account
properly in JSON RPC processing. This is no longer the case. This also affects
the GUI debug console.
- Asm script outputs replacements for OP_NOP2 and OP_NOP3
- OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP
65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)
- OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by [BIP
112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)
- The following outputs are affected by this change:
- RPC `getrawtransaction` (in verbose mode)
- RPC `decoderawtransaction`
- RPC `decodescript`
- REST `/rest/tx/` (JSON format)
- REST `/rest/block/` (JSON format when including extended tx details)
- `litecoin-tx -json`
- The sorting of the output of the `getrawmempool` output has changed.
- New RPC commands: `generatetoaddress`, `importprunedfunds`, `removeprunedfunds`, `signmessagewithprivkey`,
`getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`,
`createwitnessaddress`, `addwitnessaddress`.
- Removed RPC commands: `setgenerate`, `getgenerate`.
- New options were added to `fundrawtransaction`: `includeWatching`, `changeAddress`, `changePosition` and `feeRate`.
Low-level ZMQ changes
----------------------
- Each ZMQ notification now contains an up-counting sequence number that allows
listeners to detect lost notifications.
The sequence number is always the last element in a multi-part ZMQ notification and
therefore backward compatible. Each message type has its own counter.
PR [#7762](https://github.com/bitcoin/bitcoin/pull/7762).
Segregated witness soft fork
----------------------------
Segregated witness (segwit) is a soft fork that, if activated, will
allow transaction-producing software to separate (segregate) transaction
signatures (witnesses) from the part of the data in a transaction that is
covered by the txid. This provides several immediate benefits:
- **Elimination of unwanted transaction malleability:** Segregating the witness
allows both existing and upgraded software to calculate the transaction
identifier (txid) of transactions without referencing the witness, which can
sometimes be changed by third-parties (such as miners) or by co-signers in a
multisig spend. This solves all known cases of unwanted transaction
malleability, which is a problem that makes programming Litecoin wallet
software more difficult and which seriously complicates the design of smart
contracts for Litecoin.
- **Capacity increase:** Segwit transactions contain new fields that are not
part of the data currently used to calculate the size of a block, which
allows a block containing segwit transactions to hold more data than allowed
by the current maximum block size. Estimates based on the transactions
currently found in blocks indicate that if all wallets switch to using
segwit, the network will be able to support about 70% more transactions. The
network will also be able to support more of the advanced-style payments
(such as multisig) than it can support now because of the different weighting
given to different parts of a transaction after segwit activates (see the
following section for details).
- **Weighting data based on how it affects node performance:** Some parts of
each Litecoin block need to be stored by nodes in order to validate future
blocks; other parts of a block can be immediately forgotten (pruned) or used
only for helping other nodes sync their copy of the block chain. One large
part of the immediately prunable data are transaction signatures (witnesses),
and segwit makes it possible to give a different "weight" to segregated
witnesses to correspond with the lower demands they place on node resources.
Specifically, each byte of a segregated witness is given a weight of 1, each
other byte in a block is given a weight of 4, and the maximum allowed weight
of a block is 4 million. Weighting the data this way better aligns the most
profitable strategy for creating blocks with the long-term costs of block
validation.
- **Signature covers value:** A simple improvement in the way signatures are
generated in segwit simplifies the design of secure signature generators
(such as hardware wallets), reduces the amount of data the signature
generator needs to download, and allows the signature generator to operate
more quickly. This is made possible by having the generator sign the amount
of litecoins they think they are spending, and by having full nodes refuse to
accept those signatures unless the amount of litecoins being spent is exactly
the same as was signed. For non-segwit transactions, wallets instead had to
download the complete previous transactions being spent for every payment
they made, which could be a slow operation on hardware wallets and in other
situations where bandwidth or computation speed was constrained.
- **Linear scaling of sighash operations:** In 2015 a block was produced that
required about 25 seconds to validate on modern hardware because of the way
transaction signature hashes are performed. Other similar blocks, or blocks
that could take even longer to validate, can still be produced today. The
problem that caused this can't be fixed in a soft fork without unwanted
side-effects, but transactions that opt-in to using segwit will now use a
different signature method that doesn't suffer from this problem and doesn't
have any unwanted side-effects.
- **Increased security for multisig:** Litecoin addresses (both P2PKH addresses
that start with a '1' and P2SH addresses that start with a '3' or 'M') use a hash
function known as RIPEMD-160. For P2PKH addresses, this provides about 160
bits of security---which is beyond what cryptographers believe can be broken
today. But because P2SH is more flexible, only about 80 bits of security is
provided per address. Although 80 bits is very strong security, it is within
the realm of possibility that it can be broken by a powerful adversary.
Segwit allows advanced transactions to use the SHA256 hash function instead,
which provides about 128 bits of security (that is 281 trillion times as
much security as 80 bits and is equivalent to the maximum bits of security
believed to be provided by Litecoin's choice of parameters for its Elliptic
Curve Digital Security Algorithm [ECDSA].)
- **More efficient almost-full-node security** Satoshi Nakamoto's original
Bitcoin paper describes a method for allowing newly-started full nodes to
skip downloading and validating some data from historic blocks that are
protected by large amounts of proof of work. Unfortunately, Nakamoto's
method can't guarantee that a newly-started node using this method will
produce an accurate copy of Litecoin's current ledger (called the UTXO set),
making the node vulnerable to falling out of consensus with other nodes.
Although the problems with Nakamoto's method can't be fixed in a soft fork,
Segwit accomplishes something similar to his original proposal: it makes it
possible for a node to optionally skip downloading some blockchain data
(specifically, the segregated witnesses) while still ensuring that the node
can build an accurate copy of the UTXO set for the block chain with the most
proof of work. Segwit enables this capability at the consensus layer, but
note that Litecoin Core does not provide an option to use this capability as
of this 0.13.2 release.
- **Script versioning:** Segwit makes it easy for future soft forks to allow
Litecoin users to individually opt-in to almost any change in the Litecoin
Script language when those users receive new transactions. Features
currently being researched by Bitcoin and Litecoin Core contributors that may
use this capability include support for Schnorr signatures, which can improve
the privacy and efficiency of multisig transactions (or transactions with
multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can
improve the privacy and efficiency of scripts with two or more conditions.
Other Bitcoin community members are studying several other improvements
that can be made using script versioning.
Activation for the segwit soft fork is being managed using
BIP9. At the beginning of the first retarget period after
segwit's start date of 1 January 2017 miners can update the Litecoin
client to Litecoin Core 0.13.2 to signal for segwit support. When a
super-majority of 75% is reached segwit is activated by optional, and
if 75% of blocks within a 8,064-block retarget period (about 3.5 days)
signal support for segwit, after another 8,064 blocks, segwit will
be required.
For more information about segwit, please see the [segwit FAQ][], the
[segwit wallet developers guide][] or BIPs [141][BIP141], [143][BIP143],
[144][BIP144], and [145][BIP145].
[Segwit FAQ]: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
[segwit wallet developers guide]: https://bitcoincore.org/en/segwit_wallet_dev/
[BIP141]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
[BIP143]: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
[BIP144]: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
[BIP145]: https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki
Null dummy soft fork
-------------------
Combined with the segwit soft fork is an additional change that turns a
long-existing network relay policy into a consensus rule. The
`OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` opcodes consume an extra
stack element ("dummy element") after signature validation. The dummy
element is not inspected in any manner, and could be replaced by any
value without invalidating the script.
Because any value can be used for this dummy element, it's possible for
a third-party to insert data into other people's transactions, changing
the transaction's txid (called transaction malleability) and possibly
causing other problems.
Since Litecoin Core 0.10.0, nodes have defaulted to only relaying and
mining transactions whose dummy element was a null value (0x00, also
called OP_0). The null dummy soft fork turns this relay rule into a
consensus rule both for non-segwit transactions and segwit transactions,
so that this method of mutating transactions is permanently eliminated
from the network.
Signaling for the null dummy soft fork is done by signaling support
for segwit, and the null dummy soft fork will activate at the same time
as segwit.
For more information, please see [BIP147][].
[BIP147]: https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki
Low-level RPC changes
---------------------
- `importprunedfunds` only accepts two required arguments. Some versions accept
an optional third arg, which was always ignored. Make sure to never pass more
than two arguments.
Linux ARM builds
----------------
Pre-built Linux ARM binaries have been added to the set of uploaded executables.
Additional detail on the ARM architecture targeted by each is provided below.
The following extra files can be found in the download directory or torrent:
- `litecoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries targeting
the 32-bit ARMv7-A architecture.
- `litecoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries targeting
the 64-bit ARMv8-A architecture.
ARM builds are still experimental. If you have problems on a certain device or
Linux distribution combination please report them on the bug tracker, it may be
possible to resolve them. Note that the device you use must be (backward)
compatible with the architecture targeted by the binary that you use.
For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit
execution state) device, can run the 32-bit ARMv7-A targeted binary. However,
no model of Raspberry Pi 1 device can run either binary because they are all
ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A.
Note that Android is not considered ARM Linux in this context. The executables
are not expected to work out of the box on Android.
Change to wallet handling of mempool rejection
-----------------------------------------------
When a newly created transaction failed to enter the mempool due to
the limits on chains of unconfirmed transactions the sending RPC
calls would return an error. The transaction would still be queued
in the wallet and, once some of the parent transactions were
confirmed, broadcast after the software was restarted.
This behavior has been changed to return success and to reattempt
mempool insertion at the same time transaction rebroadcast is
attempted, avoiding a need for a restart.
Transactions in the wallet which cannot be accepted into the mempool
can be abandoned with the previously existing abandontransaction RPC
(or in the GUI via a context menu on the transaction).
Credits
=======
Thanks to everyone who directly contributed to this release:
- [The Bitcoin Core Developers](/doc/release-notes)
- Charles Lee
- Adrian Gallagher
- shaolinfry
- Xinxi Wang
- Xinrong Guo
- Fan Yang
- Peng Sun
- Loshan T

80
doc/litecoin-release-notes/release-notes-0.13.3.md
View File

@ -1,80 +0,0 @@
Litecoin Core version 0.13.3 is now available from:
<https://download.litecoin.org/litecoin-0.13.3/>
This is a new minor version release, including new features, various bugfixes and performance improvements.
It is recommended to upgrade to this version.
Please report bugs using the issue tracker at github:
<https://github.com/litecoin-project/litecoin/issues>
Compatibility
==============
Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a litecoin
wallet on a XP machine is irresponsible at least.
In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.
We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.
No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.
From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.
Notable changes
===============
New Multisig Address Prefix
---------------------------
Litecoin Core now supports P2SH addresses beginning with M on mainnet and Q on testnet.
P2SH addresses beginning with 3 on mainnet and m or n on testnet will continue to be valid.
Old and new addresses can be used interchangeably.
miniupnp CVE-2017-8798
----------------------
Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error (present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers (within the LAN) to cause a denial of service or possibly have unspecified other impact.
This only affects users that have explicitly enabled UPnP through the GUI setting or through the -upnp option, as since the last UPnP vulnerability (in Litecoin Core 0.10.4) it has been disabled by default.
If you use this option, it is recommended to upgrade to this version as soon as possible.
Reset Testnet
-------------
Testnet3 has been deprecated and replaced with Testnet4. The server port has been changed to 19335 however the RPC port remains
the same (19332).
Testnet faucets can be located at:
- http://testnet.litecointools.com
- http://testnet.thrasher.io
Developers who require the new testnet blockchain paramaters can find them [here](https://github.com/litecoin-project/litecoin/blob/0.13/src/chainparams.cpp#L214).
Credits
=======
Thanks to everyone who directly contributed to this release:
- [The Bitcoin Core Developers](/doc/release-notes)
- Adrian Gallagher
- Shaolin Fry
- Xinxi Wang
- Out0fmemory
- Erasmospunk
- Romanornr

429
doc/litecoin-release-notes/release-notes-0.14.2.md
View File

@ -1,429 +0,0 @@
Litecoin Core version 0.14.2 is now available from:
<https://download.litecoin.org/litecoin-0.14.2.0/>
This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
<https://github.com/litecoin-project/litecoin/issues>
To receive security and update notifications, please subscribe to:
<https://groups.google.com/forum/#!forum/litecoin-dev>
Compatibility
==============
Litecoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.
Litecoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes
===============
New Multisig Address Prefix
---------------------------
Litecoin Core now supports P2SH addresses beginning with M on mainnet and Q on testnet.
P2SH addresses beginning with 3 on mainnet and m or n on testnet will continue to be valid.
Old and new addresses can be used interchangeably.
miniupnp CVE-2017-8798
----------------------
Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error (present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers (within the LAN) to cause a denial of service or possibly have unspecified other impact.
This only affects users that have explicitly enabled UPnP through the GUI setting or through the -upnp option, as since the last UPnP vulnerability (in Litecoin Core 0.10.4) it has been disabled by default.
If you use this option, it is recommended to upgrade to this version as soon as possible.
Reset Testnet
-------------
Testnet3 has been deprecated and replaced with Testnet4. The server port has been changed to 19335 however the RPC port remains
the same (19332).
Testnet faucets can be located at:
- http://testnet.litecointools.com
- http://testnet.thrasher.io
Developers who require the new testnet blockchain paramaters can find them [here](https://github.com/litecoin-project/litecoin/blob/master/src/chainparams.cpp#L220).
Performance Improvements
--------------
Validation speed and network propagation performance have been greatly
improved, leading to much shorter sync and initial block download times.
- The script signature cache has been reimplemented as a "cuckoo cache",
allowing for more signatures to be cached and faster lookups.
- Assumed-valid blocks have been introduced which allows script validation to
be skipped for ancestors of known-good blocks, without changing the security
model. See below for more details.
- In some cases, compact blocks are now relayed before being fully validated as
per BIP152.
- P2P networking has been refactored with a focus on concurrency and
throughput. Network operations are no longer bottlenecked by validation. As a
result, block fetching is several times faster than previous releases in many
cases.
- The UTXO cache now claims unused mempool memory. This speeds up initial block
download as UTXO lookups are a major bottleneck there, and there is no use for
the mempool at that stage.
Manual Pruning
--------------
Litecoin Core has supported automatically pruning the blockchain since 0.13.2. Pruning
the blockchain allows for significant storage space savings as the vast majority of
the downloaded data can be discarded after processing so very little of it remains
on the disk.
Manual block pruning can now be enabled by setting `-prune=1`. Once that is set,
the RPC command `pruneblockchain` can be used to prune the blockchain up to the
specified height or timestamp.
`getinfo` Deprecated
--------------------
The `getinfo` RPC command has been deprecated. Each field in the RPC call
has been moved to another command's output with that command also giving
additional information that `getinfo` did not provide. The following table
shows where each field has been moved to:
|`getinfo` field | Moved to |
|------------------|-------------------------------------------|
`"version"` | `getnetworkinfo()["version"]`
`"protocolversion"`| `getnetworkinfo()["protocolversion"]`
`"walletversion"` | `getwalletinfo()["walletversion"]`
`"balance"` | `getwalletinfo()["balance"]`
`"blocks"` | `getblockchaininfo()["blocks"]`
`"timeoffset"` | `getnetworkinfo()["timeoffset"]`
`"connections"` | `getnetworkinfo()["connections"]`
`"proxy"` | `getnetworkinfo()["networks"][0]["proxy"]`
`"difficulty"` | `getblockchaininfo()["difficulty"]`
`"testnet"` | `getblockchaininfo()["chain"] == "test"`
`"keypoololdest"` | `getwalletinfo()["keypoololdest"]`
`"keypoolsize"` | `getwalletinfo()["keypoolsize"]`
`"unlocked_until"` | `getwalletinfo()["unlocked_until"]`
`"paytxfee"` | `getwalletinfo()["paytxfee"]`
`"relayfee"` | `getnetworkinfo()["relayfee"]`
`"errors"` | `getnetworkinfo()["warnings"]`
ZMQ On Windows
--------------
Previously the ZeroMQ notification system was unavailable on Windows
due to various issues with ZMQ. These have been fixed upstream and
now ZMQ can be used on Windows. Please see [this document](https://github.com/litecoin-project/litecoin/blob/master/doc/zmq.md) for
help with using ZMQ in general.
Nested RPC Commands in Debug Console
------------------------------------
The ability to nest RPC commands has been added to the debug console. This
allows users to have the output of a command become the input to another
command without running the commands separately.
The nested RPC commands use bracket syntax (i.e. `getwalletinfo()`) and can
be nested (i.e. `getblock(getblockhash(1))`). Simple queries can be
done with square brackets where object values are accessed with either an
array index or a non-quoted string (i.e. `listunspent()[0][txid]`). Both
commas and spaces can be used to separate parameters in both the bracket syntax
and normal RPC command syntax.
Network Activity Toggle
-----------------------
A RPC command and GUI toggle have been added to enable or disable all p2p
network activity. The network status icon in the bottom right hand corner
is now the GUI toggle. Clicking the icon will either enable or disable all
p2p network activity. If network activity is disabled, the icon will
be grayed out with an X on top of it.
Additionally the `setnetworkactive` RPC command has been added which does
the same thing as the GUI icon. The command takes one boolean parameter,
`true` enables networking and `false` disables it.
Out-of-sync Modal Info Layer
----------------------------
When Litecoin Core is out-of-sync on startup, a semi-transparent information
layer will be shown over top of the normal display. This layer contains
details about the current sync progress and estimates the amount of time
remaining to finish syncing. This layer can also be hidden and subsequently
unhidden by clicking on the progress bar at the bottom of the window.
Support for JSON-RPC Named Arguments
------------------------------------
Commands sent over the JSON-RPC interface and through the `litecoin-cli` binary
can now use named arguments. This follows the [JSON-RPC specification](http://www.jsonrpc.org/specification)
for passing parameters by-name with an object.
`litecoin-cli` has been updated to support this by parsing `name=value` arguments
when the `-named` option is given.
Some examples:
src/litecoin-cli -named help command="help"
src/litecoin-cli -named getblockhash height=0
src/litecoin-cli -named getblock blockhash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
src/litecoin-cli -named sendtoaddress address="(snip)" amount="1.0" subtractfeefromamount=true
The order of arguments doesn't matter in this case. Named arguments are also
useful to leave out arguments that should stay at their default value. The
rarely-used arguments `comment` and `comment_to` to `sendtoaddress`, for example, can
be left out. However, this is not yet implemented for many RPC calls, this is
expected to land in a later release.
The RPC server remains fully backwards compatible with positional arguments.
Sensitive Data Is No Longer Stored In Debug Console History
-----------------------------------------------------------
The debug console maintains a history of previously entered commands that can be
accessed by pressing the Up-arrow key so that users can easily reuse previously
entered commands. Commands which have sensitive information such as passphrases and
private keys will now have a `(...)` in place of the parameters when accessed through
the history.
Retaining the Mempool Across Restarts
-------------------------------------
The mempool will be saved to the data directory prior to shutdown
to a `mempool.dat` file. This file preserves the mempool so that when the node
restarts the mempool can be filled with transactions without waiting for new transactions
to be created. This will also preserve any changes made to a transaction through
commands such as `prioritisetransaction` so that those changes will not be lost.
Final Alert
-----------
The Alert System was disabled and deprecated in Litecoin Core 0.10.4 and removed in 0.13.2.
The Alert System was retired with a maximum sequence final alert which causes any nodes
supporting the Alert System to display a static hard-coded "Alert Key Compromised" message which also
prevents any other alerts from overriding it. This final alert is hard-coded into this release
so that all old nodes receive the final alert.
GUI Changes
-----------
- After resetting the options by clicking the `Reset Options` button
in the options dialog or with the `-resetguioptions` startup option,
the user will be prompted to choose the data directory again. This
is to ensure that custom data directories will be kept after the
option reset which clears the custom data directory set via the choose
datadir dialog.
- Multiple peers can now be selected in the list of peers in the debug
window. This allows for users to ban or disconnect multiple peers
simultaneously instead of banning them one at a time.
- An indicator has been added to the bottom right hand corner of the main
window to indicate whether the wallet being used is a HD wallet. This
icon will be grayed out with an X on top of it if the wallet is not a
HD wallet.
Low-level RPC changes
----------------------
- `importprunedfunds` only accepts two required arguments. Some versions accept
an optional third arg, which was always ignored. Make sure to never pass more
than two arguments.
- The first boolean argument to `getaddednodeinfo` has been removed. This is
an incompatible change.
- RPC command `getmininginfo` loses the "testnet" field in favor of the more
generic "chain" (which has been present for years).
- A new RPC command `preciousblock` has been added which marks a block as
precious. A precious block will be treated as if it were received earlier
than a competing block.
- A new RPC command `importmulti` has been added which receives an array of
JSON objects representing the intention of importing a public key, a
private key, an address and script/p2sh
- Use of `getrawtransaction` for retrieving confirmed transactions with unspent
outputs has been deprecated. For now this will still work, but in the future
it may change to only be able to retrieve information about transactions in
the mempool or if `txindex` is enabled.
- A new RPC command `getmemoryinfo` has been added which will return information
about the memory usage of Litecoin Core. This was added in conjunction with
optimizations to memory management. See [Pull #8753](https://github.com/bitcoin/bitcoin/pull/8753)
for more information.
- A new RPC command `bumpfee` has been added which allows replacing an
unconfirmed wallet transaction that signaled RBF (see the `-walletrbf`
startup option above) with a new transaction that pays a higher fee, and
should be more likely to get confirmed quickly.
- The first positional argument of `createrawtransaction` was renamed from
`transactions` to `inputs`.
- The argument of `disconnectnode` was renamed from `node` to `address`.
Client software using these calls with named arguments needs to be updated.
HTTP REST Changes
-----------------
- UTXO set query (`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>
/.../<txid>-<n>.<bin|hex|json>`) responses were changed to return status
code `HTTP_BAD_REQUEST` (400) instead of `HTTP_INTERNAL_SERVER_ERROR` (500)
when requests contain invalid parameters.
Minimum Fee Rate Policies
-------------------------
Since the changes in 0.13 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set `-minrelaytxfee`. With this release the following concepts that were tied to this option have been separated out:
- calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB)
- minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new `-blockmintxfee` option. (defaults to 1000 satoshis/kB)
The `-minrelaytxfee` option continues to exist but is recommended to be left unset.
Fee Estimation Changes
----------------------
- Since 0.13.2 fee estimation for a confirmation target of 1 block has been
disabled. The fee slider will no longer be able to choose a target of 1 block.
This is only a minor behavior change as there was often insufficient
data for this target anyway. `estimatefee 1` will now always return -1 and
`estimatesmartfee 1` will start searching at a target of 2.
- The default target for fee estimation is changed to 6 blocks in both the GUI
(previously 25) and for RPC calls (previously 2).
Removal of Priority Estimation
------------------------------
- Estimation of "priority" needed for a transaction to be included within a target
number of blocks has been removed. The RPC calls are deprecated and will either
return -1 or 1e24 appropriately. The format for `fee_estimates.dat` has also
changed to no longer save these priority estimates. It will automatically be
converted to the new format which is not readable by prior versions of the
software.
- Support for "priority" (coin age) transaction sorting for mining is
considered deprecated in Core and will be removed in the next major version.
This is not to be confused with the `prioritisetransaction` RPC which will remain
supported by Core for adding fee deltas to transactions.
P2P connection management
--------------------------
- Peers manually added through the `-addnode` option or `addnode` RPC now have their own
limit of eight connections which does not compete with other inbound or outbound
connection usage and is not subject to the limitation imposed by the `-maxconnections`
option.
- New connections to manually added peers are performed more quickly.
Introduction of assumed-valid blocks
-------------------------------------
- A significant portion of the initial block download time is spent verifying
scripts/signatures. Although the verification must pass to ensure the security
of the system, no other result from this verification is needed: If the node
knew the history of a given block were valid it could skip checking scripts
for its ancestors.
- A new configuration option 'assumevalid' is provided to express this knowledge
to the software. Unlike the 'checkpoints' in the past this setting does not
force the use of a particular chain: chains that are consistent with it are
processed quicker, but other chains are still accepted if they'd otherwise
be chosen as best. Also unlike 'checkpoints' the user can configure which
block history is assumed true, this means that even outdated software can
sync more quickly if the setting is updated by the user.
- Because the validity of a chain history is a simple objective fact it is much
easier to review this setting. As a result the software ships with a default
value adjusted to match the current chain shortly before release. The use
of this default value can be disabled by setting -assumevalid=0
Fundrawtransaction change address reuse
----------------------------------------
- Before 0.14, `fundrawtransaction` was by default wallet stateless. In
almost all cases `fundrawtransaction` does add a change-output to the
outputs of the funded transaction. Before 0.14, the used keypool key was
never marked as change-address key and directly returned to the keypool
(leading to address reuse). Before 0.14, calling `getnewaddress`
directly after `fundrawtransaction` did generate the same address as
the change-output address.
- Since 0.14, fundrawtransaction does reserve the change-output-key from
the keypool by default (optional by setting `reserveChangeKey`, default =
`true`)
- Users should also consider using `getrawchangeaddress()` in conjunction
with `fundrawtransaction`'s `changeAddress` option.
Unused mempool memory used by coincache
----------------------------------------
- Before 0.14, memory reserved for mempool (using the `-maxmempool` option)
went unused during initial block download, or IBD. In 0.14, the UTXO DB cache
(controlled with the `-dbcache` option) borrows memory from the mempool
when there is extra memory available. This may result in an increase in
memory usage during IBD for those previously relying on only the `-dbcache`
option to limit memory during that time.
Mining
------
In previous versions, getblocktemplate required segwit support from downstream
clients/miners once the feature activated on the network. In this version, it
now supports non-segwit clients even after activation, by removing all segwit
transactions from the returned block template. This allows non-segwit miners to
continue functioning correctly even after segwit has activated.
Due to the limitations in previous versions, getblocktemplate also recommended
non-segwit clients to not signal for the segwit version-bit. Since this is no
longer an issue, getblocktemplate now always recommends signalling segwit for
all miners. This is safe because ability to enforce the rule is the only
required criteria for safe activation, not actually producing segwit-enabled
blocks.
UTXO memory accounting
----------------------
Memory usage for the UTXO cache is being calculated more accurately, so that
the configured limit (`-dbcache`) will be respected when memory usage peaks
during cache flushes. The memory accounting in prior releases is estimated to
only account for half the actual peak utilization.
The default `-dbcache` has also been changed in this release to 450MiB. Users
who currently set `-dbcache` to a high value (e.g. to keep the UTXO more fully
cached in memory) should consider increasing this setting in order to achieve
the same cache performance as prior releases. Users on low-memory systems
(such as systems with 1GB or less) should consider specifying a lower value for
this parameter.
Additional information relating to running on low-memory systems can be found
here, originally written for Bitcoin but can also be used for Litecoin:
[reducing-bitcoind-memory-usage.md](https://gist.github.com/laanwj/efe29c7661ce9b6620a7).
Credits
=======
Thanks to everyone who directly contributed to this release:
- [The Bitcoin Core Developers](/doc/release-notes)
- Adrian Gallagher
- Charlie Lee
- Loshan T
- Shaolin Fry
- Xinxi Wang

773
doc/litecoin-release-notes/release-notes-0.15.0.1.md
View File

@ -1,773 +0,0 @@
Litecoin Core version *0.15.0* is now available from:
<https://download.litecoin.org/litecoin-0.15.0/>
This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
<https://github.com/litecoin-project/litecoin/issues>
To receive security and update notifications, please subscribe to:
<https://groups.google.com/forum/#!forum/litecoin-dev>
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/Litecoin-Qt` (on Mac)
or `litecoind`/`litecoin-qt` (on Linux).
The first time you run version 0.15.0, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.
The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
downgrade from version 0.15.0 or upgrade to version 0.15.0 will cause all fee
estimates to be discarded.
Note that the block database format also changed in version 0.8.0 and there is no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not supported.
However, as usual, old wallet versions are still supported.
Downgrading warning
-------------------
The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the `-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.
If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.
Compatibility
==============
Litecoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.
Litecoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes
===============
Performance Improvements
------------------------
Version 0.15 contains a number of significant performance improvements, which make
Initial Block Download, startup, transaction and block validation much faster:
- The chainstate database (which is used for tracking UTXOs) has been changed
from a per-transaction model to a per-output model (See [PR 10195](https://github.com/bitcoin/bitcoin/pull/10195)). Advantages of this model
are that it:
- avoids the CPU overhead of deserializing and serializing the unused outputs;
- has more predictable memory usage;
- uses simpler code;
- is adaptable to various future cache flushing strategies.
As a result, validating the blockchain during Initial Block Download (IBD) and reindex
is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less frequently.
The only downside is that the on-disk database is 15% larger. During the conversion from the previous format
a few extra gigabytes may be used.
- Earlier versions experienced a spike in memory usage while flushing UTXO updates to disk.
As a result, only half of the available memory was actually used as cache, and the other half was
reserved to accommodate flushing. This is no longer the case (See [PR 10148](https://github.com/bitcoin/bitcoin/pull/10148)), and the entirety of
the available cache (see `-dbcache`) is now actually used as cache. This reduces the flushing
frequency by a factor 2 or more.
- In previous versions, signature validation for transactions has been cached when the
transaction is accepted to the mempool. Version 0.15 extends this to cache the entire script
validity (See [PR 10192](https://github.com/bitcoin/bitcoin/pull/10192)). This means that if a transaction in a block has already been accepted to the
mempool, the scriptSig does not need to be re-evaluated. Empirical tests show that
this results in new block validation being 40-50% faster.
- LevelDB has been upgraded to version 1.20 (See [PR 10544](https://github.com/bitcoin/bitcoin/pull/10544)). This version contains hardware acceleration for CRC
on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.
- SHA256 hashing has been optimized for architectures supporting SSE 4 (See [PR 10821](https://github.com/bitcoin/bitcoin/pull/10821)). SHA256 is around
50% faster on supported hardware, which results in around 5% faster IBD and block
validation. In version 0.15, SHA256 hardware optimization is disabled in release builds by
default, but can be enabled by using `--enable-experimental-asm` when building.
- Refill of the keypool no longer flushes the wallet between each key which resulted in a ~20x speedup in creating a new wallet. Part of this speedup was used to increase the default keypool to 1000 keys to make recovery more robust. (See [PR 10831](https://github.com/bitcoin/bitcoin/pull/10831)).
- Scrypt hashing has been optimized for architectures supporting SSE 2 (See [PR 362](https://github.com/litecoin-project/litecoin/pull/362)). This boosts scrypt hashing performance by a factor of 2. In version 0.15, scrypt hardware optimization is disabled in release builds by default, but can be enabled by using `--enable-sse2` when building.
Fee Estimation Improvements
---------------------------
Fee estimation has been significantly improved in version 0.15, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the `estimatesmartfee` and `estimaterawfee` RPCs (See [PR 10199](https://github.com/bitcoin/bitcoin/pull/10199)).
### Changes to internal logic and wallet behavior
- Internally, estimates are now tracked on 3 different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions.
- Estimates can now be *conservative* or *economical*. *Conservative* estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. *Economical* estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly.
- By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be 'bumped' if the fee conditions change rapidly (See [PR 10589](https://github.com/bitcoin/bitcoin/pull/10589)).
- Estimates can now be made for confirmation targets up to 1008 blocks (one week).
- More data on historical fee rates is stored, leading to more precise fee estimates.
- Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates.
- The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used.
### Changes to fee estimate RPCs
- The `estimatefee` RPC is now deprecated in favor of using only `estimatesmartfee` (which is the implementation used by the GUI)
- The `estimatesmartfee` RPC interface has been changed (See [PR 10707](https://github.com/bitcoin/bitcoin/pull/10707)):
- The `nblocks` argument has been renamed to `conf_target` (to be consistent with other RPC methods).
- An `estimate_mode` argument has been added. This argument takes one of the following strings: `CONSERVATIVE`, `ECONOMICAL` or `UNSET` (which defaults to `CONSERVATIVE`).
- The RPC return object now contains an `errors` member, which returns errors encountered during processing.
- If Litecoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).
- A new `estimaterawfee` RPC is added to provide raw fee data. External clients can query and use this data in their own fee estimation logic.
Opt into RBF When Sending
-------------------------
A new startup option, `-walletrbf`, has been added to allow users to have all
transactions sent opt into RBF support. The default value for this option is
currently `false`, so transactions will not opt into RBF by default. The new
`bumpfee` RPC can be used to replace transactions that opt into RBF.
Replace-by-fee control in the GUI
---------------------------------
In version 0.15, creating an opt-in RBF transaction and replacing the unconfirmed transaction with a higher-fee transaction are both supported in the GUI (See PR 9592).
Multi-wallet support
--------------------
Litecoin Core now supports loading multiple, separate wallets (See [PR 8694](https://github.com/bitcoin/bitcoin/pull/8694), [PR 10849](https://github.com/bitcoin/bitcoin/pull/10849)). The wallets are completely separated, with individual balances, keys and received transactions.
Multi-wallet is enabled by using more than one `-wallet` argument when starting Litecoin, either on the command line or in the Litecoin config file.
**In Litecoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions.** GUI selectable multiple wallets will be supported in a future version. However, even in 0.15 other loaded wallets will remain synchronized to the node's current tip in the background. This can be useful if running a pruned node, since loading a wallet where the most recent sync is beyond the pruned height results in having to download and revalidate the whole blockchain. Continuing to synchronize all wallets in the background avoids this problem.
Litecoin Core 0.15.0 contains the following changes to the RPC interface and `litecoin-cli` for multi-wallet:
* When running Litecoin Core with a single wallet, there are **no** changes to the RPC interface or `litecoin-cli`. All RPC calls and `litecoin-cli` commands continue to work as before.
* When running Litecoin Core with multi-wallet, all *node-level* RPC methods continue to work as before. HTTP RPC requests should be send to the normal `<RPC IP address>:<RPC port>/` endpoint, and `litecoin-cli` commands should be run as before. A *node-level* RPC method is any method which does not require access to the wallet.
* When running Litecoin Core with multi-wallet, *wallet-level* RPC methods must specify the wallet for which they're intended in every request. HTTP RPC requests should be send to the `<RPC IP address>:<RPC port>/wallet/<wallet name>/` endpoint, for example `127.0.0.1:9332/wallet/wallet1.dat/`. `litecoin-cli` commands should be run with a `-rpcwallet` option, for example `litecoin-cli -rpcwallet=wallet1.dat getbalance`.
* A new *node-level* `listwallets` RPC method is added to display which wallets are currently loaded. The names returned by this method are the same as those used in the HTTP endpoint and for the `rpcwallet` argument.
Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 0.15.0, and there may backwards-incompatible changes in future versions.
Removal of Coin Age Priority
----------------------------
In previous versions of Litecoin Core, a portion of each block could be reserved for transactions based on the age and value of UTXOs they spent. This concept (Coin Age Priority) is a policy choice by miners, and there are no consensus rules around the inclusion of Coin Age Priority transactions in blocks. In practice, only a few miners continue to use Coin Age Priority for transaction selection in blocks. Litecoin Core 0.15 removes all remaining support for Coin Age Priority (See [PR 9602](https://github.com/bitcoin/bitcoin/pull/9602)). This has the following implications:
- The concept of *free transactions* has been removed. High Coin Age Priority transactions would previously be allowed to be relayed even if they didn't attach a miner fee. This is no longer possible since there is no concept of Coin Age Priority. The `-limitfreerelay` and `-relaypriority` options which controlled relay of free transactions have therefore been removed.
- The `-sendfreetransactions` option has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
- The `-blockprioritysize` option has been removed.
- The `estimatepriority` and `estimatesmartpriority` RPCs have been removed.
- The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`.
- The `prioritisetransaction` RPC no longer takes a `priority_delta` argument, which is replaced by a `dummy` argument for backwards compatibility with clients using positional arguments. The RPC is still used to change the apparent fee-rate of the transaction by using the `fee_delta` argument.
- `-minrelaytxfee` can now be set to 0. If `minrelaytxfee` is set, then fees smaller than `minrelaytxfee` (per kB) are rejected from relaying, mining and transaction creation. This defaults to 1000 satoshi/kB.
- The `-printpriority` option has been updated to only output the fee rate and hash of transactions included in a block by the mining code.
Mempool Persistence Across Restarts
-----------------------------------
Version 0.14 introduced mempool persistence across restarts (the mempool is saved to a `mempool.dat` file in the data directory prior to shutdown and restores the mempool when the node is restarted). Version 0.15 allows this feature to be switched on or off using the `-persistmempool` command-line option (See [PR 9966](https://github.com/bitcoin/bitcoin/pull/9966)). By default, the option is set to true, and the mempool is saved on shutdown and reloaded on startup. If set to false, the `mempool.dat` file will not be loaded on startup or saved on shutdown.
New RPC methods
---------------
Version 0.15 introduces several new RPC methods:
- `abortrescan` stops current wallet rescan, e.g. when triggered by an `importprivkey` call (See [PR 10208](https://github.com/bitcoin/bitcoin/pull/10208)).
- `combinerawtransaction` accepts a JSON array of raw transactions and combines them into a single raw transaction (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)).
- `estimaterawfee` returns raw fee data so that customized logic can be implemented to analyze the data and calculate estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface.
- `getchaintxstats` returns statistics about the total number and rate of transactions
in the chain (See [PR 9733](https://github.com/bitcoin/bitcoin/pull/9733)).
- `listwallets` lists wallets which are currently loaded. See the *Multi-wallet* section
of these release notes for full details (See [Multi-wallet support](#multi-wallet-support)).
- `uptime` returns the total runtime of the `bitcoind` server since its last start (See [PR 10400](https://github.com/bitcoin/bitcoin/pull/10400)).
Low-level RPC changes
---------------------
- When using Litecoin Core in multi-wallet mode, RPC requests for wallet methods must specify
the wallet that they're intended for. See [Multi-wallet support](#multi-wallet-support) for full details.
- The new database model no longer stores information about transaction
versions of unspent outputs (See [Performance improvements](#performance-improvements)). This means that:
- The `gettxout` RPC no longer has a `version` field in the response.
- The `gettxoutsetinfo` RPC reports `hash_serialized_2` instead of `hash_serialized`,
which does not commit to the transaction versions of unspent outputs, but does
commit to the height and coinbase information.
- The `getutxos` REST path no longer reports the `txvers` field in JSON format,
and always reports 0 for transaction versions in the binary format
- The `estimatefee` RPC is deprecated. Clients should switch to using the `estimatesmartfee` RPC, which returns better fee estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface.
- The `gettxoutsetinfo` response now contains `disk_size` and `bogosize` instead of
`bytes_serialized`. The first is a more accurate estimate of actual disk usage, but
is not deterministic. The second is unrelated to disk usage, but is a
database-independent metric of UTXO set size: it counts every UTXO entry as 50 + the
length of its scriptPubKey (See [PR 10426](https://github.com/bitcoin/bitcoin/pull/10426)).
- `signrawtransaction` can no longer be used to combine multiple transactions into a single transaction. Instead, use the new `combinerawtransaction` RPC (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)).
- `fundrawtransaction` no longer accepts a `reserveChangeKey` option. This option used to allow RPC users to fund a raw transaction using an key from the keypool for the change address without removing it from the available keys in the keypool. The key could then be re-used for a `getnewaddress` call, which could potentially result in confusing or dangerous behaviour (See [PR 10784](https://github.com/bitcoin/bitcoin/pull/10784)).
- `estimatepriority` and `estimatesmartpriority` have been removed. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
- The `listunspent` RPC now takes a `query_options` argument (see [PR 8952](https://github.com/bitcoin/bitcoin/pull/8952)), which is a JSON object
containing one or more of the following members:
- `minimumAmount` - a number specifying the minimum value of each UTXO
- `maximumAmount` - a number specifying the maximum value of each UTXO
- `maximumCount` - a number specifying the minimum number of UTXOs
- `minimumSumAmount` - a number specifying the minimum sum value of all UTXOs
- The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
- The `dumpwallet` RPC now returns the full absolute path to the dumped wallet. It
used to return no value, even if successful (See [PR 9740](https://github.com/bitcoin/bitcoin/pull/9740)).
- In the `getpeerinfo` RPC, the return object for each peer now returns an `addrbind` member, which contains the ip address and port of the connection to the peer. This is in addition to the `addrlocal` member which contains the ip address and port of the local node as reported by the peer (See [PR 10478](https://github.com/bitcoin/bitcoin/pull/10478)).
- The `disconnectnode` RPC can now disconnect a node specified by node ID (as well as by IP address/port). To disconnect a node based on node ID, call the RPC with the new `nodeid` argument (See [PR 10143](https://github.com/bitcoin/bitcoin/pull/10143)).
- The second argument in `prioritisetransaction` has been renamed from `priority_delta` to `dummy` since Bitcoin Core no longer has a concept of coin age priority. The `dummy` argument has no functional effect, but is retained for positional argument compatibility. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).
- The `resendwallettransactions` RPC throws an error if the `-walletbroadcast` option is set to false (See [PR 10995](https://github.com/bitcoin/bitcoin/pull/10995)).
- The second argument in the `submitblock` RPC argument has been renamed from `parameters` to `dummy`. This argument never had any effect, and the renaming is simply to communicate this fact to the user (See [PR 10191](https://github.com/bitcoin/bitcoin/pull/10191))
(Clients should, however, use positional arguments for `submitblock` in order to be compatible with BIP 22.)
- The `verbose` argument of `getblock` has been renamed to `verbosity` and now takes an integer from 0 to 2. Verbose level 0 is equivalent to `verbose=false`. Verbose level 1 is equivalent to `verbose=true`. Verbose level 2 will give the full transaction details of each transaction in the output as given by `getrawtransaction`. The old behavior of using the `verbose` named argument and a boolean value is still maintained for compatibility.
- Error codes have been updated to be more accurate for the following error cases (See [PR 9853](https://github.com/bitcoin/bitcoin/pull/9853)):
- `getblock` now returns RPC_MISC_ERROR if the block can't be found on disk (for
example if the block has been pruned). Previously returned RPC_INTERNAL_ERROR.
- `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND.
- `pruneblockchain` now returns RPC_INVALID_PARAMETER if the blocks cannot be pruned
because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR.
- `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR.
- `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address
or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED.
- `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the user tries to unban
a node that has not previously been banned. Previously returned RPC_MISC_ERROR.
- `removeprunedfunds` now returns RPC_WALLET_ERROR if `bitcoind` is unable to remove
the transaction. Previously returned RPC_INTERNAL_ERROR.
- `removeprunedfunds` now returns RPC_INVALID_PARAMETER if the transaction does not
exist in the wallet. Previously returned RPC_INTERNAL_ERROR.
- `fundrawtransaction` now returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change
address is provided. Previously returned RPC_INVALID_PARAMETER.
- `fundrawtransaction` now returns RPC_WALLET_ERROR if `bitcoind` is unable to create
the transaction. The error message provides further details. Previously returned
RPC_INTERNAL_ERROR.
- `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
descendants in the wallet. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
descendants in the mempool. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has
has been mined or conflicts with a mined transaction. Previously returned
RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction is not
BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has already
been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction contains
inputs which don't belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has multiple change
outputs. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has no change
output. Previously returned RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the fee is too high. Previously returned
RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the fee is too low. Previously returned
RPC_MISC_ERROR.
- `bumpfee` now returns RPC_WALLET_ERROR if the change output is too small to bump the
fee. Previously returned RPC_MISC_ERROR.
0.15.0 Change log
=================
### RPC and other APIs
- #9485 `61a640e` ZMQ example using python3 and asyncio (mcelrath)
- #9894 `0496e15` remove 'label' filter for rpc command help (instagibbs)
- #9853 `02bd6e9` Fix error codes from various RPCs (jnewbery)
- #9842 `598ef9c` Fix RPC failure testing (continuation of #9707) (jnewbery)
- #10038 `d34995a` Add mallocinfo mode to `getmemoryinfo` RPC (laanwj)
- #9500 `3568b30` [Qt][RPC] Autocomplete commands for 'help' command in debug console (achow101)
- #10056 `e6156a0` [zmq] Call va_end() on va_start()ed args (kallewoof)
- #10086 `7438cea` Trivial: move rpcserialversion into RPC option group (jlopp)
- #10150 `350b224` [rpc] Add logging rpc (jnewbery)
- #10208 `393160c` [wallet] Rescan abortability (kallewoof)
- #10143 `a987def` [net] Allow disconnectnode RPC to be called with node id (jnewbery)
- #10281 `0e8499c` doc: Add RPC interface guidelines (laanwj)
- #9733 `d4732f3` Add getchaintxstats RPC (sipa)
- #10310 `f4b15e2` [doc] Add hint about getmempoolentry to getrawmempool help (kallewoof)
- #8704 `96c850c` [RPC] Transaction details in getblock (achow101)
- #8952 `9390845` Add query options to listunspent RPC call (pedrobranco)
- #10413 `08ac35a` Fix docs (there's no rpc command setpaytxfee) (RHavar)
- #8384 `e317c0d` Add witness data output to TxInError messages (instagibbs)
- #9571 `4677151` RPC: getblockchaininfo returns BIP signaling statistics (pinheadmz)
- #10450 `ef2d062` Fix bumpfee rpc "errors" return value (ryanofsky)
- #10475 `39039b1` [RPC] getmempoolinfo mempoolminfee is a BTC/KB feerate (instagibbs)
- #10478 `296928e` rpc: Add listen address to incoming connections in `getpeerinfo` (laanwj)
- #10403 `08d0390` Fix importmulti failure to return rescan errors (ryanofsky)
- #9740 `9fec4da` Add friendly output to dumpwallet (aideca)
- #10426 `16f6c98` Replace bytes_serialized with bogosize (sipa)
- #10252 `980deaf` RPC/Mining: Restore API compatibility for prioritisetransaction (luke-jr)
- #9672 `46311e7` Opt-into-RBF for RPC & bitcoin-tx (luke-jr)
- #10481 `9c248e3` Decodehextx scripts sanity check (achow101)
- #10488 `fa1f106` Note that the prioritizetransaction dummy value is deprecated, and has no meaning (TheBlueMatt)
- #9738 `c94b89e` gettxoutproof() should return consistent result (jnewbery)
- #10191 `00350bd` [trivial] Rename unused RPC arguments 'dummy' (jnewbery)
- #10627 `b62b4c8` fixed listunspent rpc convert parameter (tnakagawa)
- #10412 `bef02fb` Improve wallet rescan API (ryanofsky)
- #10400 `1680ee0` [RPC] Add an uptime command that displays the amount of time (in seconds) bitcoind has been running (rvelhote)
- #10683 `d81bec7` rpc: Move the `generate` RPC call to rpcwallet (laanwj)
- #10710 `30bc0f6` REST/RPC example update (Mirobit)
- #10747 `9edda0c` [rpc] fix verbose argument for getblock in bitcoin-cli (jnewbery)
- #10589 `104f5f2` More economical fee estimates for RBF and RPC options to control (morcos)
- #10543 `b27b004` Change API to estimaterawfee (morcos)
- #10807 `afd2fca` getbalance example covers at least 6 confirms (instagibbs)
- #10707 `75b5643` Better API for estimatesmartfee RPC (morcos)
- #10784 `9e8d6a3` Do not allow users to get keys from keypool without reserving them (TheBlueMatt)
- #10857 `d445a2c` [RPC] Add a deprecation warning to getinfo's output (achow101)
- #10571 `adf170d` [RPC]Move transaction combining from signrawtransaction to new RPC (achow101)
- #10783 `041dad9` [RPC] Various rpc argument fixes (instagibbs)
- #9622 `6ef3c7e` [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block (kallewoof)
- #10799 `8537187` Prevent user from specifying conflicting parameters to fundrawtx (TheBlueMatt)
- #10931 `0b11a07` Fix misleading "Method not found" multiwallet errors (ryanofsky)
- #10788 `f66c596` [RPC] Fix addwitnessaddress by replacing ismine with producesignature (achow101)
- #10999 `627c3c0` Fix amounts formatting in `decoderawtransaction` (laanwj)
- #11002 `4268426` [wallet] return correct error code from resendwallettransaction (jnewbery)
- #11029 `96a63a3` [RPC] trivial: gettxout no longer shows version of tx (FelixWeis)
- #11083 `6c2b008` Fix combinerawtransaction RPC help result section (jonasnick)
- #11027 `07164bb` [RPC] Only return hex field once in getrawtransaction (achow101)
- #10698 `5af6572` Be consistent in calling transactions "replaceable" for Opt-In RBF (TheBlueMatt)
### Block and transaction handling
- #9801 `a8c5751` Removed redundant parameter from mempool.PrioritiseTransaction (gubatron)
- #9819 `1efc99c` Remove harmless read of unusued priority estimates (morcos)
- #9822 `b7547fa` Remove block file location upgrade code (benma)
- #9602 `30ff3a2` Remove coin age priority and free transactions - implementation (morcos)
- #9548 `47510ad` Remove min reasonable fee (morcos)
- #10249 `c73af54` Switch CCoinsMap from boost to std unordered_map (sipa)
- #9966 `2a183de` Control mempool persistence using a command line parameter (jnewbery)
- #10199 `318ea50` Better fee estimates (morcos)
- #10196 `bee3529` Bugfix: PrioritiseTransaction updates the mempool tx counter (sdaftuar)
- #10195 `1088b02` Switch chainstate db and cache to per-txout model (sipa)
- #10284 `c2ab38b` Always log debug information for fee calculation in CreateTransaction (morcos)
- #10503 `efbcf2b` Use REJECT_DUPLICATE for already known and conflicted txn (sipa)
- #10537 `b3eb0d6` Few Minor per-utxo assert-semantics re-adds and tweak (TheBlueMatt)
- #10626 `8c841a3` doc: Remove outdated minrelaytxfee comment (MarcoFalke)
- #10559 `234ffc6` Change semantics of HaveCoinInCache to match HaveCoin (morcos)
- #10581 `7878353` Simplify return values of GetCoin/HaveCoin(InCache) (sipa)
- #10684 `a381f6a` Remove no longer used mempool.exists(outpoint) (morcos)
- #10148 `d4e551a` Use non-atomic flushing with block replay (sipa)
- #10685 `30c2130` Clarify CCoinsViewMemPool documentation (TheBlueMatt)
- #10558 `90a002e` Address nits from per-utxo change (morcos)
- #10706 `6859ad2` Improve wallet fee logic and fix GUI bugs (morcos)
- #10526 `754aa02` Force on-the-fly compaction during pertxout upgrade (sipa)
- #10985 `d896d5c` Add undocumented -forcecompactdb to force LevelDB compactions (sipa)
- #10292 `e4bbd3d` Improved efficiency in COutPoint constructors (mm-s)
- #10290 `8d6d43e` Add -stopatheight for benchmarking (sipa)
### P2P protocol and network code
- #9726 `7639d38` netbase: Do not print an error on connection timeouts through proxy (laanwj)
- #9805 `5b583ef` Add seed.btc.petertodd.org to mainnet DNS seeds (petertodd)
- #9861 `22f609f` Trivial: Debug log ambiguity fix for peer addrs (keystrike)
- #9774 `90cb2a2` Enable host lookups for -proxy and -onion parameters (jmcorgan)
- #9558 `7b585cf` Clarify assumptions made about when BlockCheck is called (TheBlueMatt)
- #10135 `e19586a` [p2p] Send the correct error code in reject messages (jnewbery)
- #9665 `eab00d9` Use cached [compact] blocks to respond to getdata messages (TheBlueMatt)
- #10215 `a077a90` Check interruptNet during dnsseed lookups (TheBlueMatt)
- #10234 `faf2dea` [net] listbanned RPC and QT should show correct banned subnets (jnewbery)
- #10134 `314ebdf` [qa] Fixes segwit block relay test after inv-direct-fetch was disabled (sdaftuar)
- #10351 `3f57c55` removed unused code in INV message (Greg-Griffith)
- #10061 `ae78609` [net] Added SetSocketNoDelay() utility function (tjps)
- #10408 `28c6e8d` Net: Improvements to Tor control port parser (str4d)
- #10460 `5c63d66` Broadcast address every day, not 9 hours (sipa)
- #10471 `400fdd0` Denote functions CNode::GetRecvVersion() and CNode::GetRefCount() as const (pavlosantoniou)
- #10345 `67700b3` [P2P] Timeout for headers sync (sdaftuar)
- #10564 `8d9f45e` Return early in IsBanned (gmaxwell)
- #10587 `de8db47` Net: Fix resource leak in ReadBinaryFile(...) (practicalswift)
- #9549 `b33ca14` [net] Avoid possibility of NULL pointer dereference in MarkBlockAsInFlight(...) (practicalswift)
- #10446 `2772dc9` net: avoid extra dns query per seed (theuni)
- #10824 `9dd6a2b` Avoid unnecessary work in SetNetworkActive (promag)
- #10948 `df3a6f4` p2p: Hardcoded seeds update pre-0.15 branch (laanwj)
- #10977 `02f4c4a` [net] Fix use of uninitialized value in getnetworkinfo(const JSONRPCRequest&) (practicalswift)
- #10982 `c8b62c7` Disconnect network service bits 6 and 8 until Aug 1, 2018 (TheBlueMatt)
- #11012 `0e5cff6` Make sure to clean up mapBlockSource if we've already seen the block (theuni)
### Validation
- #9725 `67023e9` CValidationInterface Cleanups (TheBlueMatt)
- #10178 `2584925` Remove CValidationInterface::UpdatedTransaction (TheBlueMatt)
- #10201 `a6548a4` pass Consensus::Params& to functions in validation.cpp and make them static (mariodian)
- #10297 `431a548` Simplify DisconnectBlock arguments/return value (sipa)
- #10464 `f94b7d5` Introduce static DoWarning (simplify UpdateTip) (jtimon)
- #10569 `2e7d8f8` Fix stopatheight (achow101)
- #10192 `2935b46` Cache full script execution results in addition to signatures (TheBlueMatt)
- #10179 `21ed30a` Give CValidationInterface Support for calling notifications on the CScheduler Thread (TheBlueMatt)
- #10557 `66270a4` Make check to distinguish between orphan txs and old txs more efficient (morcos)
- #10775 `7c2400c` nCheckDepth chain height fix (romanornr)
- #10821 `16240f4` Add SSE4 optimized SHA256 (sipa)
- #10854 `04d395e` Avoid using sizes on non-fixed-width types to derive protocol constants (gmaxwell)
- #10945 `2a50b11` Update defaultAssumeValid according to release-process.md (gmaxwell)
- #10986 `2361208` Update chain transaction statistics (sipa)
- #11028 `6bdf4b3` Avoid masking of difficulty adjustment errors by checkpoints (sipa)
- #9533 `cb598cf` Allow non-power-of-2 signature cache sizes (sipa)
- #9208 `acd9957` Improve DisconnectTip performance (sdaftuar)
- #10618 `f90603a` Remove confusing MAX_BLOCK_BASE_SIZE (gmaxwell)
- #10758 `bd92424` Fix some chainstate-init-order bugs (TheBlueMatt)
- #10550 `b7296bc` Don't return stale data from CCoinsViewCache::Cursor() (ryanofsky)
- #10998 `2507fd5` Fix upgrade cancel warnings (TheBlueMatt)
- #9868 `cbdb473` Abstract out the command line options for block assembly (sipa)
### Build system
- #9727 `5f0556d` Remove fallbacks for boost_filesystem < v3 (laanwj)
- #9788 `50a2265` gitian: bump descriptors for master (theuni)
- #9794 `7ca2f54` Minor update to qrencode package builder (mitchellcash)
- #9514 `2cc0df1` release: Windows signing script (theuni)
- #9921 `8b789d8` build: Probe MSG_DONTWAIT in the same way as MSG_NOSIGNAL (laanwj)
- #10011 `32d1b34` build: Fix typo s/HAVE_DONTWAIT/HAVE_MSG_DONTWAIT (laanwj)
- #9946 `90dd9e6` Fix build errors if spaces in path or parent directory (pinheadmz)
- #10136 `81da4c7` build: Disable Wshadow warning (laanwj)
- #10166 `64962ae` Ignore Doxyfile generated from Doxyfile.in template (paveljanik)
- #10239 `0416ea9` Make Boost use std::atomic internally (sipa)
- #10228 `27faa6c` build: regenerate bitcoin-config.h as necessary (theuni)
- #10273 `8979f45` [scripts] Minor improvements to `macdeployqtplus` script (chrisgavin)
- #10325 `a26280b` 0.15.0 Depends Updates (fanquake)
- #10328 `79aeff6` Update contrib/debian to latest Ubuntu PPA upload (TheBlueMatt)
- #7522 `d25449f` Bugfix: Only use git for build info if the repository is actually the right one (luke-jr)
- #10489 `e654d61` build: silence gcc7's implicit fallthrough warning (theuni)
- #10549 `ad1a13e` Avoid printing generic and duplicated "checking for QT" during ./configure (drizzt)
- #10628 `8465b68` [depends] expat 2.2.1 (fanquake)
- #10806 `db825d2` build: verify that the assembler can handle crc32 functions (theuni)
- #10766 `b4d03be` Building Environment: Set ARFLAGS to cr (ReneNyffenegger)
- #10803 `91edda8` Explicitly search for bdb5.3 (pstratem)
- #10855 `81560b0` random: only use getentropy on openbsd (theuni)
- #10508 `1caafa6` Run Qt wallet tests on travis (ryanofsky)
- #10851 `e222618` depends: fix fontconfig with newer glibc (theuni)
- #10971 `88b1e4b` build: fix missing sse42 in depends builds (theuni)
- #11097 `129b03f` gitian: quick hack to fix version string in releases (theuni)
- #10039 `919aaf6` Fix compile errors with Qt 5.3.2 and Boost 1.55.0 (ryanofsky)
- #10168 `7032021` Fix build warning from #error text (jnewbery)
- #10301 `318392c` Check if sys/random.h is required for getentropy (jameshilliard)
### GUI
- #9724 `1a9fd5c` Qt/Intro: Add explanation of IBD process (luke-jr)
- #9834 `b00ba62` qt: clean up initialize/shutdown signals (benma)
- #9481 `ce01e62` [Qt] Show more significant warning if we fall back to the default fee (jonasschnelli)
- #9974 `b9f930b` Add basic Qt wallet test (ryanofsky)
- #9690 `a387d3a` Change 'Clear' button string to 'Reset' (da2x)
- #9592 `9c7b7cf` [Qt] Add checkbox in the GUI to opt-in to RBF when creating a transaction (ryanofsky)
- #10098 `2b477e6` Make qt wallet test compatible with qt4 (ryanofsky)
- #9890 `1fa4ae6` Add a button to open the config file in a text editor (ericshawlinux)
- #10156 `51833a1` Fix for issues with startup and multiple monitors on windows (AllanDoensen)
- #10177 `de01da7` Changed "Send" button default status from true to false (KibbledJiveElkZoo)
- #10221 `e96486c` Stop treating coinbase outputs differently in GUI: show them at 1conf (TheBlueMatt)
- #10231 `987a6c0` [Qt] Reduce a significant cs_main lock freeze (jonasschnelli)
- #10242 `f6f3b58` [qt] Don't call method on null WalletModel object (ryanofsky)
- #10093 `a3e756b` [Qt] Don't add arguments of sensitive command to console window (jonasschnelli)
- #10362 `95546c8` [GUI] Add OSX keystroke to RPCConsole info (spencerlievens)
- #9697 `962cd3f` [Qt] simple fee bumper with user verification (jonasschnelli)
- #10390 `e477516` [wallet] remove minimum total fee option (instagibbs)
- #10420 `4314544` Add Qt tests for wallet spends & bumpfee (ryanofsky)
- #10454 `c1c9a95` Fix broken q4 test build (ryanofsky)
- #10449 `64beb13` Overhaul Qt fee bumper (jonasschnelli)
- #10582 `7c72fb9` Pass in smart fee slider value to coin control dialog (morcos)
- #10673 `4c72cc3` [qt] Avoid potential null pointer dereference in TransactionView::exportClicked() (practicalswift)
- #10769 `8fdd23a` [Qt] replace fee slider with a Dropdown, extend conf. targets (jonasschnelli)
- #10870 `412b466` [Qt] Use wallet 0 in rpc console if running with multiple wallets (jonasschnelli)
- #10988 `a9dd111` qt: Increase BLOCK_CHAIN_SIZE constants (laanwj)
- #10644 `e292140` Slightly overhaul NSI pixmaps (jonasschnelli)
- #10660 `0c3542e` Allow to cancel the txdb upgrade via splashscreen keypress 'q' (jonasschnelli)
### Wallet
- #9359 `f7ec7cf` Add test for CWalletTx::GetImmatureCredit() returning stale values (ryanofsky)
- #9576 `56ab672` [wallet] Remove redundant initialization (practicalswift)
- #9333 `fa625b0` Document CWalletTx::mapValue entries and remove erase of nonexistent "version" entry (ryanofsky)
- #9906 `72fb515` Disallow copy constructor CReserveKeys (instagibbs)
- #9369 `3178b2c` Factor out CWallet::nTimeSmart computation into a method (ryanofsky)
- #9830 `afcd7c0` Add safe flag to listunspent result (NicolasDorier)
- #9993 `c49355c` Initialize nRelockTime (pstratem)
- #9818 `3d857f3` Save watch only key timestamps when reimporting keys (ryanofsky)
- #9294 `f34cdcb` Use internal HD chain for change outputs (hd split) (jonasschnelli)
- #10164 `e183ea2` Wallet: reduce excess logic InMempool() (kewde)
- #10186 `c9ff4f8` Remove SYNC_TRANSACTION_NOT_IN_BLOCK magic number (jnewbery)
- #10226 `64c45aa` wallet: Use boost to more portably ensure -wallet specifies only a filename (luke-jr)
- #9827 `c91ca0a` Improve ScanForWalletTransactions return value (ryanofsky)
- #9951 `fa1ac28` Wallet database handling abstractions/simplifications (laanwj)
- #10265 `c29a0d4` [wallet] [moveonly] Check non-null pindex before potentially referencing (kallewoof)
- #10283 `a550f6e` Cleanup: reduce to one GetMinimumFee call signature (morcos)
- #10294 `e2b99b1` [Wallet] unset change position when there is no change (instagibbs)
- #10115 `d3dce0e` Avoid reading the old hd master key during wallet encryption (TheBlueMatt)
- #10341 `18c9deb` rpc/wallet: Workaround older UniValue which returns a std::string temporary for get_str (luke-jr)
- #10308 `94e5227` [wallet] Securely erase potentially sensitive keys/values (tjps)
- #10257 `ea1fd43` [test] Add test for getmemoryinfo (jimmysong)
- #10295 `ce8176d` [qt] Move some WalletModel functions into CWallet (ryanofsky)
- #10506 `7cc2c67` Fix bumpfee test after #10449 (ryanofsky)
- #10500 `098b01d` Avoid CWalletTx copies in GetAddressBalances and GetAddressGroupings (ryanofsky)
- #10455 `0747d33` Simplify feebumper minimum fee code slightly (ryanofsky)
- #10522 `2805d60` [wallet] Remove unused variables (practicalswift)
- #8694 `177433a` Basic multiwallet support (luke-jr)
- #10598 `7a74f88` Supress struct/class mismatch warnings introduced in #10284 (paveljanik)
- #9343 `209eef6` Don't create change at dust limit (morcos)
- #10744 `ed88e31` Use method name via __func__ macro (darksh1ne)
- #10712 `e8b9523` Add change output if necessary to reduce excess fee (morcos)
- #10816 `1c011ff` Properly forbid -salvagewallet and -zapwallettxes for multi wallet (morcos)
- #10235 `5cfdda2` Track keypool entries as internal vs external in memory (TheBlueMatt)
- #10330 `bf0a08b` [wallet] fix zapwallettxes interaction with persistent mempool (jnewbery)
- #10831 `0b01935` Batch flushing operations to the walletdb during top up and increase keypool size (gmaxwell)
- #10795 `7b6e8bc` No longer ever reuse keypool indexes (TheBlueMatt)
- #10849 `bde4f93` Multiwallet: simplest endpoint support (jonasschnelli)
- #10817 `9022aa3` Redefine Dust and add a discard_rate (morcos)
- #10883 `bf3b742` Rename -usewallet to -rpcwallet (morcos)
- #10604 `420238d` [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test (jnewbery)
- #10885 `70888a3` Reject invalid wallets (promag)
- #10949 `af56397` Clarify help message for -discardfee (morcos)
- #10942 `2e857bb` Eliminate fee overpaying edge case when subtracting fee from recipients (morcos)
- #10995 `fa64636` Fix resendwallettransactions assert failure if -walletbroadcast=0 (TheBlueMatt)
- #11022 `653a46d` Basic keypool topup (jnewbery)
- #11081 `9fe1f6b` Add length check for CExtKey deserialization (jonasschnelli, guidovranken)
- #11044 `4ef8374` [wallet] Keypool topup cleanups (jnewbery)
- #11145 `e51bb71` Fix rounding bug in calculation of minimum change (morcos)
- #9605 `779f2f9` Use CScheduler for wallet flushing, remove ThreadFlushWalletDB (TheBlueMatt)
- #10108 `4e3efd4` ApproximateBestSubset should take inputs by reference, not value (RHavar)
### Tests and QA
- #9744 `8efd1c8` Remove unused module from rpc-tests (34ro)
- #9657 `7ff4a53` Improve rpc-tests.py (jnewbery)
- #9766 `7146d96` Add --exclude option to rpc-tests.py (jnewbery)
- #9577 `d6064a8` Fix docstrings in qa tests (jnewbery)
- #9823 `a13a417` qa: Set correct path for binaries in rpc tests (MarcoFalke)
- #9847 `6206252` Extra test vector for BIP32 (sipa)
- #9350 `88c2ae3` [Trivial] Adding label for amount inside of tx_valid/tx_invalid.json (Christewart)
- #9888 `36afd4d` travis: Verify commits only for one target (MarcoFalke)
- #9904 `58861ad` test: Fail if InitBlockIndex fails (laanwj)
- #9828 `67c5cc1` Avoid -Wshadow warnings in wallet_tests (ryanofsky)
- #9832 `48c3429` [qa] assert_start_raises_init_error (NicolasDorier)
- #9739 `9d5fcbf` Fix BIP68 activation test (jnewbery)
- #9547 `d32581c` bench: Assert that division by zero is unreachable (practicalswift)
- #9843 `c78adbf` Fix segwit getblocktemplate test (jnewbery)
- #9929 `d5ce14e` tests: Delete unused function _rpchost_to_args (laanwj)
- #9555 `19be26a` [test] Avoid reading a potentially uninitialized variable in tx_invalid-test (transaction_tests.cpp) (practicalswift)
- #9945 `ac23a7c` Improve logging in bctest.py if there is a formatting mismatch (jnewbery)
- #9768 `8910b47` [qa] Add logging to test_framework.py (jnewbery)
- #9972 `21833f9` Fix extended rpc tests broken by #9768 (jnewbery)
- #9977 `857d1e1` QA: getblocktemplate_longpoll.py should always use >0 fee tx (sdaftuar)
- #9970 `3cc13ea` Improve readability of segwit.py, smartfees.py (sdaftuar)
- #9497 `2c781fb` CCheckQueue Unit Tests (JeremyRubin)
- #10024 `9225de2` [trivial] Use log.info() instead of print() in remaining functional test cases (jnewbery)
- #9956 `3192e52` Reorganise qa directory (jnewbery)
- #10017 `02d64bd` combine_logs.py - aggregates log files from multiple bitcoinds during functional tests (jnewbery)
- #10047 `dfef6b6` [tests] Remove unused variables and imports (practicalswift)
- #9701 `a230b05` Make bumpfee tests less fragile (ryanofsky)
- #10053 `ca20923` [test] Allow functional test cases to be skipped (jnewbery)
- #10052 `a0b1e57` [test] Run extended tests once daily in Travis (jnewbery)
- #10069 `1118493` [QA] Fix typo in fundrawtransaction test (NicolasDorier)
- #10083 `c044f03` [QA] Renaming rawTx into rawtx (NicolasDorier)
- #10073 `b1a4f27` Actually run assumevalid.py (jnewbery)
- #9780 `c412fd8` Suppress noisy output from qa tests in Travis (jnewbery)
- #10096 `79af9fb` Check that all test scripts in test/functional are being run (jnewbery)
- #10076 `5b029aa` [qa] combine_logs: Use ordered list for logfiles (MarcoFalke)
- #10107 `f2734c2` Remove unused variable. Remove accidental trailing semicolons in Python code (practicalswift)
- #10109 `8ac8041` Remove SingleNodeConnCB (jnewbery)
- #10114 `edc62c9` [tests] sync_with_ping should assert that ping hasn't timed out (jnewbery)
- #10128 `427d2fd` Speed Up CuckooCache tests (JeremyRubin)
- #10072 `12af74b` Remove sources of unreliablility in extended functional tests (jnewbery)
- #10077 `ebfd653` [qa] Add setnetworkactive smoke test (MarcoFalke)
- #10152 `080d7c7` [trivial] remove unused line in Travis config (jnewbery)
- #10159 `df1ca9e` [tests] color test results and sort alphabetically (jnewbery)
- #10124 `88799ea` [test] Suppress test logging spam (jnewbery)
- #10142 `ed09dd3` Run bitcoin_test-qt under minimal QPA platform (ryanofsky)
- #9949 `a27dbc5` [bench] Avoid function call arguments which are pointers to uninitialized values (practicalswift)
- #10187 `b44adf9` tests: Fix test_runner return value in case of skipped test (laanwj)
- #10197 `d86bb07` [tests] Functional test warnings (jnewbery)
- #10219 `9111df9` Tests: Order Python Tests Differently (jimmysong)
- #10229 `f3db4c6` Tests: Add test for getdifficulty (jimmysong)
- #10224 `2723bcd` [test] Add test for getaddednodeinfo (jimmysong)
- #10023 `c530c15` [tests] remove maxblocksinflight.py (functionality covered by other test) (jnewbery)
- #10097 `1b25b6d` Move zmq test skipping logic into individual test case (jnewbery)
- #10272 `54e2d87` [Tests] Prevent warning: variable 'x' is uninitialized (paveljanik)
- #10225 `e0a7e19` [test] Add aborttrescan tests (kallewoof)
- #10278 `8254a8a` [test] Add Unit Test for GetListenPort (jimmysong)
- #10280 `47535d7` [test] Unit test amount.h/amount.cpp (jimmysong)
- #10256 `80c3a73` [test] Add test for gettxout to wallet.py (jimmysong)
- #10264 `492d22f` [test] Add tests for getconnectioncount, getnettotals and ping (jimmysong)
- #10169 `8f3e384` [tests] Remove func test code duplication (jnewbery)
- #10198 `dc8fc0c` [tests] Remove is_network_split from functional test framework (jnewbery)
- #10255 `3c5e6c9` [test] Add test for listaddressgroupings (jimmysong)
- #10137 `75171f0` Remove unused import. Remove accidental trailing semicolons (practicalswift)
- #10307 `83073de` [tests] allow zmq test to be run in out-of-tree builds (jnewbery)
- #10344 `e927483` [tests] Fix abandonconflict.py intermittency (jnewbery)
- #10318 `170bc2c` [tests] fix wait_for_inv() (jnewbery)
- #10171 `fff72de` [tests] Add node methods to test framework (jnewbery)
- #10352 `23d78c4` test: Add elapsed time to RPC tracing (laanwj)
- #10342 `6a796b2` [tests] Improve mempool_persist test (jnewbery)
- #10287 `776ba23` [tests] Update Unit Test for addrman.h/addrman.cpp (jimmysong)
- #10365 `7ee5236` [tests] increase timeouts in sendheaders test (jnewbery)
- #10361 `f6241b3` qa: disablewallet: Check that wallet is really disabled (MarcoFalke)
- #10371 `4b766fc` [tests] Clean up addrman_tests.cpp (jimmysong)
- #10253 `87abe20` [test] Add test for getnetworkhashps (jimmysong)
- #10376 `8bd16ee` [tests] fix disconnect_ban intermittency (jnewbery)
- #10374 `5411997` qa: Warn when specified test is not found (MarcoFalke)
- #10405 `0542978` tests: Correct testcase in script_tests.json for large number OP_EQUAL (laanwj)
- #10429 `6b99daf` tests: fix spurious addrman test failure (theuni)
- #10433 `8e57256` [tests] improve tmpdir structure (jnewbery)
- #10415 `217b416` [tests] Speed up fuzzing by ~200x when using afl-fuzz (practicalswift)
- #10445 `b4b057a` Add test for empty chain and reorg consistency for gettxoutsetinfo (gmaxwell)
- #10423 `1aefc94` [tests] skipped tests should clean up after themselves (jnewbery)
- #10359 `329fc1d` [tests] functional tests should call BitcoinTestFramework start/stop node methods (jnewbery)
- #10514 `e103b3f` Bugfix: missing == 0 after randrange (sipa)
- #10515 `c871f32` [test] Add test for getchaintxstats (jimmysong)
- #10509 `bea5b00` Remove xvfb configuration from travis (ryanofsky)
- #10535 `30853e1` [qa] fundrawtx: Fix shutdown race (MarcoFalke)
- #9909 `300f8e7` tests: Add FindEarliestAtLeast test for edge cases (ryanofsky)
- #10331 `75e898c` Share config between util and functional tests (jnewbery)
- #10321 `e801084` Use FastRandomContext for all tests (sipa)
- #10524 `6c2d81f` [tests] Remove printf(...) (practicalswift)
- #10547 `71ab6e5` [tests] Use FastRandomContext instead of boost::random::{mt19937,uniform_int_distribution} (practicalswift)
- #10551 `6702617` [Tests] Wallet encryption functional tests (achow101)
- #10555 `643fa0b` [tests] various improvements to zmq_test.py (jnewbery)
- #10533 `d083bd9` [tests] Use cookie auth instead of rpcuser and rpcpassword (achow101)
- #10632 `c68a9a6` qa: Add stopatheight test (MarcoFalke)
- #10636 `4bc853b` [qa] util: Check return code after closing bitcoind proc (MarcoFalke)
- #10662 `e0a7801` Initialize randomness in benchmarks (achow101)
- #10612 `7c87a9c` The young person's guide to the test_framework (jnewbery)
- #10659 `acb1153` [qa] blockchain: Pass on closed connection during generate call (MarcoFalke)
- #10690 `416af3e` [qa] Bugfix: allow overriding extra_args in ComparisonTestFramework (sdaftuar)
- #10556 `65cc7aa` Move stop/start functions from utils.py into BitcoinTestFramework (jnewbery)
- #10704 `dd07f47` [tests] nits in dbcrash.py (jnewbery)
- #10743 `be82498` [test] don't run dbcrash.py on Travis (jnewbery)
- #10761 `d3b5870` [tests] fix replace_by_fee.py (jnewbery)
- #10759 `1d4805c` Fix multi_rpc test for hosts that dont default to utf8 (TheBlueMatt)
- #10190 `e4f226a` [tests] mining functional tests (including regression test for submitblock) (jnewbery)
- #10739 `1fc783f` test: Move variable `state` down where it is used (paveljanik)
- #9980 `fee0d80` Fix mem access violation merkleblock (Christewart)
- #10893 `0c173a1` [QA] Avoid running multiwallet.py twice (jonasschnelli)
- #10927 `9d5e8f9` test: Make sure wallet.backup is created in temp path (laanwj)
- #10899 `f29d5db` [test] Qt: Use _putenv_s instead of setenv on Windows builds (brianmcmichael)
- #10912 `5c8eb79` [tests] Fix incorrect memory_cleanse(…) call in crypto_tests.cpp (practicalswift)
- #11001 `fa8a063` [tests] Test disconnecting unsupported service bits logic (jnewbery)
- #10695 `929fd72` [qa] Rewrite BIP65/BIP66 functional tests (sdaftuar)
- #10963 `ecd2135` [bench] Restore format state of cout after printing with std::fixed/setprecision (practicalswift)
- #11025 `e5d26e4` qa: Fix inv race in example_test (MarcoFalke)
- #10765 `2c811e0` Tests: address placement should be deterministic by default (ReneNyffenegger)
- #11000 `ac016e1` test: Add resendwallettransactions functional tests (promag)
- #11032 `aeb3175` [qa] Fix block message processing error in sendheaders.py (sdaftuar)
- #10105 `0b9fb68` [tests] fixup - make all Travis test runs quiet, non just cron job runs (jnewbery)
- #10222 `6ce7337` [tests] test_runner - check unicode (jnewbery)
- #10327 `35da2ae` [tests] remove import-abort-rescan.py (jnewbery)
- #11023 `bf74d37` [tests] Add option to attach a python debugger if functional test fails (jnewbery)
- #10565 `8c2098a` [coverage] Remove subtrees and benchmarks from coverage report (achow101)
### Miscellaneous
- #9871 `be8ba2c` Add a tree sha512 hash to merge commits (sipa)
- #9821 `d19d45a` util: Specific GetOSRandom for Linux/FreeBSD/OpenBSD (laanwj)
- #9903 `ba80a68` Docs: add details to -rpcclienttimeout doc (ian-kelling)
- #9910 `53c300f` Docs: correct and elaborate -rpcbind doc (ian-kelling)
- #9905 `01b7cda` [contrib] gh-merge: Move second sha512 check to the end (MarcoFalke)
- #9880 `4df8213` Verify Tree-SHA512s in merge commits, enforce sigs are not SHA1 (TheBlueMatt)
- #9932 `00c13ea` Fix verify-commits on travis and always check top commit's tree (TheBlueMatt)
- #9952 `6996e06` Add historical release notes for 0.14.0 (laanwj)
- #9940 `fa99663` Fix verify-commits on OSX, update for new bad Tree-SHA512, point travis to different keyservers (TheBlueMatt)
- #9963 `8040ae6` util: Properly handle errors during log message formatting (laanwj)
- #9984 `cce056d` devtools: Make github-merge compute SHA512 from git, instead of worktree (laanwj)
- #9995 `8bcf934` [doc] clarify blockchain size and pruning (askmike)
- #9734 `0c17afc` Add updating of chainTxData to release process (sipa)
- #10063 `530fcbd` add missing spaces so that markdown recognizes headline (flack)
- #10085 `db1ae54` Docs: remove 'noconnect' option (jlopp)
- #10090 `8e4f7e7` Update bitcoin.conf with example for pruning (coinables)
- #9424 `1a5aaab` Change LogAcceptCategory to use uint32_t rather than sets of strings (gmaxwell)
- #10036 `fbf36ca` Fix init README format to render correctly on github (jlopp)
- #10058 `a2cd0b0` No need to use OpenSSL malloc/free (tjps)
- #10123 `471ed00` Allow debug logs to be excluded from specified component (jnewbery)
- #10104 `fadf078` linearize script: Option to use RPC cookie (achow101)
- #10162 `a3a2160` [trivial] Log calls to getblocktemplate (jnewbery)
- #10155 `928695b` build: Deduplicate version numbers (laanwj)
- #10211 `a86255b` [doc] Contributor fixes & new "finding reviewers" section (kallewoof)
- #10250 `1428f30` Fix some empty vector references (sipa)
- #10270 `95f5e44` Remove Clang workaround for Boost 1.46 (fanquake)
- #10263 `cb007e4` Trivial: fix fee estimate write error log message (CryptAxe)
- #9670 `bd9ec0e` contrib: github-merge improvements (laanwj)
- #10260 `1d75597` [doc] Minor corrections to osx dependencies (fanquake)
- #10189 `750c5a5` devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private (theuni)
- #10322 `bc64b5a` Use hardware timestamps in RNG seeding (sipa)
- #10381 `7f2b9e0` Shadowing warnings are not enabled by default, update doc accordingly (paveljanik)
- #10380 `b6ee855` [doc] Removing comments about dirty entries on txmempool (madeo)
- #10383 `d0c37ee` [logging] log system time and mock time (jnewbery)
- #10404 `b45a52a` doc: Add logging to FinalizeNode() (sdaftuar)
- #10388 `526e839` Output line to debug.log when IsInitialBlockDownload latches to false (morcos)
- #10372 `15254e9` Add perf counter data to GetStrongRandBytes state in scheduler (TheBlueMatt)
- #10461 `55b72f3` Update style guide (sipa)
- #10486 `10e8c0a` devtools: Retry after signing fails in github-merge (laanwj)
- #10447 `f259263` Make bitcoind invalid argument error message specific (laanwj)
- #10495 `6a38b79` contrib: Update location of seeds.txt (laanwj)
- #10469 `b6b150b` Fixing typo in rpcdump.cpp help message (keystrike)
- #10451 `27b9931` contrib/init/bitcoind.openrcconf: Don't disable wallet by default (luke-jr)
- #10323 `00d3692` Update to latest libsecp256k1 master (sipa)
- #10422 `cec9e1e` Fix timestamp in fee estimate debug message (morcos)
- #10566 `5d034ee` [docs] Use the "domain name setup" image (previously unused) in the gitian docs (practicalswift)
- #10534 `a514ac3` Clarify prevector::erase and avoid swap-to-clear (sipa)
- #10575 `22ec768` Header include guideline (sipa)
- #10480 `fbf5d3b` Improve commit-check-script.sh (sipa)
- #10502 `1ad3d4e` scripted-diff: Remove BOOST_FOREACH, Q_FOREACH and PAIRTYPE (jtimon)
- #10377 `b63be2c` Use rdrand as entropy source on supported platforms (sipa)
- #9895 `228c319` Turn TryCreateDirectory() into TryCreateDirectories() (benma)
- #10602 `d76e84a` Make clang-format use C++11 features (e.g. A<A<int>> instead of A<A<int> >) (practicalswift)
- #10623 `c38f540` doc: Add 0.14.2 release notes (MarcoFalke)
- #10276 `b750b33` contrib/verifybinaries: allow filtering by platform (knocte)
- #10248 `01c4b14` Rewrite addrdb with less duplication using CHashVerifier (sipa)
- #10577 `232508f` Add an explanation of quickly hashing onto a non-power of two range (gmaxwell)
- #10608 `eee398f` Add a comment explaining the use of MAX_BLOCK_BASE_SIZE (gmaxwell)
- #10728 `7397af9` fix typo in help text for removeprunedfunds (AkioNak)
- #10193 `6dbcc74` scripted-diff: Remove #include <boost/foreach.hpp> (jtimon)
- #10676 `379aed0` document script-based return fields for validateaddress (instagibbs)
- #10651 `cef4b5c` Verify binaries from bitcoincore.org and bitcoin.org (TheBlueMatt)
- #10786 `ca4c545` Add PR description to merge commit in github-merge.py (sipa)
- #10812 `c5904e8` [utils] Allow bitcoin-cli's -rpcconnect option to be used with square brackets (jnewbery)
- #10842 `3895e25` Fix incorrect Doxygen tag (@ince → @since). Doxygen parameter name matching (practicalswift)
- #10681 `df0793f` add gdb attach process to test README (instagibbs)
- #10789 `1124328` Punctuation/grammer fixes in rpcwallet.cpp (stevendlander)
- #10655 `78f307b` Properly document target_confirmations in listsinceblock (RHavar)
- #10917 `5c003cb` developer-notes: add reference to snake_case and PascalCase (benma)
- #11003 `4b5a7ce` Docs: Capitalize bullet points in CONTRIBUTING guide (eklitzke)
- #10968 `98aa3f6` Add instructions for parallel gitian builds (coblee)
- #11076 `1c4b9b3` 0.15 release-notes nits: fix redundancy, remove accidental parenthesis & fix range style (practicalswift)
- #11090 `8f0121c` Update contributor names in release-notes.md (Derek701)
- #11056 `cbdd338` disable jni in builds (instagibbs)
- #11080 `2b59cfb` doc: Update build-openbsd for 6.1 (laanwj)
- #11119 `0a6af47` [doc] build-windows: Mention that only trusty works (MarcoFalke)
- #11108 `e8ad101` Changing -txindex requires -reindex, not -reindex-chainstate (TheBlueMatt)
- #9792 `342b9bc` FastRandomContext improvements and switch to ChaCha20 (sipa)
- #9505 `67ed40e` Prevector Quick Destruct (JeremyRubin)
- #10820 `ef37f20` Use cpuid intrinsics instead of asm code (sipa)
- #9999 `a328904` [LevelDB] Plug leveldb logs to bitcoin logs (NicolasDorier)
- #9693 `c5e9e42` Prevent integer overflow in ReadVarInt (gmaxwell)
- #10129 `351d0ad` scheduler: fix sub-second precision with boost < 1.50 (theuni)
- #10153 `fade788` logging: Fix off-by-one for shrinkdebugfile default (MarcoFalke)
- #10305 `c45da32` Fix potential NPD introduced in b297426c (TheBlueMatt)
- #10338 `daf3e7d` Maintain state across GetStrongRandBytes calls (sipa)
- #10544 `a4fe077` Update to LevelDB 1.20 (sipa)
- #10614 `cafe24f` random: fix crash on some 64bit platforms (theuni)
- #10714 `2a09a38` Avoid printing incorrect block indexing time due to uninitialized variable (practicalswift)
- #10837 `8bc6d1f` Fix resource leak on error in GetDevURandom (corebob)
- #10832 `89bb036` init: Factor out AppInitLockDataDirectory and fix startup core dump issue (laanwj)
- #10914 `b995a37` Add missing lock in CScheduler::AreThreadsServicingQueue() (TheBlueMatt)
- #10958 `659c096` Update to latest Bitcoin patches for LevelDB (sipa)
- #10919 `c1c671f` Fix more init bugs (TheBlueMatt)
Credits
=======
Thanks to everyone who directly contributed to this release:
- [The Bitcoin Core Developers](/doc/release-notes)
- Adrian Gallagher
- aunyks
- coblee
- gabrieldov
- romanornr
- shaolinfry
- ultragtx
- voidmain
- xinxi

6
doc/man/Makefile.am
View File

@ -1,13 +1,13 @@
dist_man1_MANS=
if BUILD_BITCOIND
dist_man1_MANS+=litecoind.1
dist_man1_MANS+=zorrod.1
endif
if ENABLE_QT
dist_man1_MANS+=litecoin-qt.1
dist_man1_MANS+=zorro-qt.1
endif
if BUILD_BITCOIN_UTILS
dist_man1_MANS+=litecoin-cli.1 litecoin-tx.1
dist_man1_MANS+=zorro-cli.1 zorro-tx.1
endif

30
doc/man/litecoin-cli.1 → doc/man/zorro-cli.1
View File

@ -1,17 +1,17 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIN-CLI "1" "February 2018" "litecoin-cli v0.15.1.0" "User Commands"
.TH ZORRO-CLI "1" "February 2018" "zorro-cli v0.15.1.0" "User Commands"
.SH NAME
litecoin-cli \- manual page for litecoin-cli v0.15.1.0
zorro-cli \- manual page for zorro-cli v0.15.1.0
.SH DESCRIPTION
Litecoin Core RPC client version v0.15.1.0\-dirty
Zorro Core RPC client version v0.15.1.0\-dirty
.SS "Usage:"
.TP
litecoin\-cli [options] <command> [params]
Send command to Litecoin Core
zorro\-cli [options] <command> [params]
Send command to Zorro Core
.IP
litecoin\-cli [options] \fB\-named\fR <command> [name=value] ... Send command to Litecoin Core (with named arguments)
litecoin\-cli [options] help List commands
litecoin\-cli [options] help <command> Get help for a command
zorro\-cli [options] \fB\-named\fR <command> [name=value] ... Send command to Zorro Core (with named arguments)
zorro\-cli [options] help List commands
zorro\-cli [options] help <command> Get help for a command
.SH OPTIONS
.HP
\-?
@ -20,7 +20,7 @@ This help message
.HP
\fB\-conf=\fR<file>
.IP
Specify configuration file (default: litecoin.conf)
Specify configuration file (default: zorro.conf)
.HP
\fB\-datadir=\fR<dir>
.IP
@ -48,7 +48,7 @@ Send commands to node running on <ip> (default: 127.0.0.1)
.HP
\fB\-rpcport=\fR<port>
.IP
Connect to JSON\-RPC on <port> (default: 9332 or testnet: 19332)
Connect to JSON\-RPC on <port> (default: 18642 or testnet: 19063)
.HP
\fB\-rpcwait\fR
.IP
@ -75,16 +75,16 @@ Read extra arguments from standard input, one per line until EOF/Ctrl\-D
\fB\-rpcwallet=\fR<walletname>
.IP
Send RPC for non\-default wallet on RPC server (argument is wallet
filename in litecoind directory, required if litecoind/\-Qt runs
filename in zorrod directory, required if zorrod/\-Qt runs
with multiple wallets)
.SH COPYRIGHT
Copyright (C) 2011-2018 The Litecoin Core developers
Copyright (C) 2011-2018 The Zorro Core developers
Copyright (C) 2009-2018 The Bitcoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
Please contribute if you find Zorro Core useful. Visit
<https://cryptogera.com> for further information about the software.
The source code is available from
<https://github.com/litecoin-project/litecoin>.
<https://git.cryptogera.com/cryptogera/zorro>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING

38
doc/man/litecoin-qt.1 → doc/man/zorro-qt.1
View File

@ -1,12 +1,12 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIN-QT "1" "February 2018" "litecoin-qt v0.15.1.0" "User Commands"
.TH ZORRO-QT "1" "February 2018" "zorro-qt v0.15.1.0" "User Commands"
.SH NAME
litecoin-qt \- manual page for litecoin-qt v0.15.1.0
zorro-qt \- manual page for zorro-qt v0.15.1.0
.SH DESCRIPTION
Litecoin Core version v0.15.1.0\-dirty (64\-bit)
Zorro Core version v0.15.1.0\-dirty (64\-bit)
Usage:
.IP
litecoin\-qt [command\-line options]
zorro\-qt [command\-line options]
.SH OPTIONS
.HP
\-?
@ -38,7 +38,7 @@ a0afbded94d4be233e191525dc2d467af5c7eab3143c852c3cd549831022aad6)
.HP
\fB\-conf=\fR<file>
.IP
Specify configuration file (default: litecoin.conf)
Specify configuration file (default: zorro.conf)
.HP
\fB\-datadir=\fR<dir>
.IP
@ -81,7 +81,7 @@ leave that many cores free, default: 0)
.HP
\fB\-pid=\fR<file>
.IP
Specify pid file (default: litecoin.pid)
Specify pid file (default: zorro.pid)
.HP
\fB\-prune=\fR<n>
.IP
@ -206,7 +206,7 @@ Support filtering of blocks and transaction with bloom filters (default:
.HP
\fB\-port=\fR<port>
.IP
Listen for connections on <port> (default: 9333 or testnet: 19335)
Listen for connections on <port> (default: 18641 or testnet: 19062)
.HP
\fB\-proxy=\fR<ip:port>
.IP
@ -268,12 +268,12 @@ Set key pool size to <n> (default: 1000)
.HP
\fB\-fallbackfee=\fR<amt>
.IP
A fee rate (in LTC/kB) that will be used when fee estimation has
A fee rate (in ZRR/kB) that will be used when fee estimation has
insufficient data (default: 0.02)
.HP
\fB\-discardfee=\fR<amt>
.IP
The fee rate (in LTC/kB) that indicates your tolerance for discarding
The fee rate (in ZRR/kB) that indicates your tolerance for discarding
change by adding it to the fee (default: 0.0001). Note: An output
is discarded if it is dust at this rate, but we will always
discard up to the dust relay fee and a discard fee above that is
@ -281,12 +281,12 @@ limited by the fee estimate for the longest target
.HP
\fB\-mintxfee=\fR<amt>
.IP
Fees (in LTC/kB) smaller than this are considered zero fee for
Fees (in ZRR/kB) smaller than this are considered zero fee for
transaction creation (default: 0.001)
.HP
\fB\-paytxfee=\fR<amt>
.IP
Fee (in LTC/kB) to add to transactions you send (default: 0.00)
Fee (in ZRR/kB) to add to transactions you send (default: 0.00)
.HP
\fB\-rescan\fR
.IP
@ -391,7 +391,7 @@ Prepend debug output with timestamp (default: 1)
.HP
\fB\-maxtxfee=\fR<amt>
.IP
Maximum total fees (in LTC) to use in a single wallet transaction or raw
Maximum total fees (in ZRR) to use in a single wallet transaction or raw
transaction; setting this too low may abort large transactions
(default: 0.10)
.HP
@ -431,7 +431,7 @@ Enable transaction replacement in the memory pool (default: 0)
.HP
\fB\-minrelaytxfee=\fR<amt>
.IP
Fees (in LTC/kB) smaller than this are considered zero fee for relaying,
Fees (in ZRR/kB) smaller than this are considered zero fee for relaying,
mining and transaction creation (default: 0.00001)
.HP
\fB\-whitelistrelay\fR
@ -457,7 +457,7 @@ blockmaxweight
.HP
\fB\-blockmintxfee=\fR<amt>
.IP
Set lowest fee rate (in LTC/kB) for transactions to be included in block
Set lowest fee rate (in ZRR/kB) for transactions to be included in block
creation. (default: 0.00001)
.PP
RPC server options:
@ -502,7 +502,7 @@ option can be specified multiple times
.HP
\fB\-rpcport=\fR<port>
.IP
Listen for JSON\-RPC connections on <port> (default: 9332 or testnet:
Listen for JSON\-RPC connections on <port> (default: 18642 or testnet:
19332)
.HP
\fB\-rpcallowip=\fR<ip>
@ -547,13 +547,13 @@ Show splash screen on startup (default: 1)
.IP
Reset all settings changed in the GUI
.SH COPYRIGHT
Copyright (C) 2011-2018 The Litecoin Core developers
Copyright (C) 2011-2018 The Zorro Core developers
Copyright (C) 2009-2018 The Bitcoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
Please contribute if you find Zorro Core useful. Visit
<https://cryptogera.com> for further information about the software.
The source code is available from
<https://github.com/litecoin-project/litecoin>.
<https://git.cryptogera.com/cryptogera/zorro>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING

22
doc/man/litecoin-tx.1 → doc/man/zorro-tx.1
View File

@ -1,16 +1,16 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIN-TX "1" "February 2018" "litecoin-tx v0.15.1.0" "User Commands"
.TH ZORRO-TX "1" "February 2018" "zorro-tx v0.15.1.0" "User Commands"
.SH NAME
litecoin-tx \- manual page for litecoin-tx v0.15.1.0
zorro-tx \- manual page for zorro-tx v0.15.1.0
.SH DESCRIPTION
Litecoin Core litecoin\-tx utility version v0.15.1.0\-dirty
Zorro Core zorro\-tx utility version v0.15.1.0\-dirty
.SS "Usage:"
.TP
litecoin\-tx [options] <hex\-tx> [commands]
Update hex\-encoded litecoin transaction
zorro\-tx [options] <hex\-tx> [commands]
Update hex\-encoded zorro transaction
.TP
litecoin\-tx [options] \fB\-create\fR [commands]
Create hex\-encoded litecoin transaction
zorro\-tx [options] \fB\-create\fR [commands]
Create hex\-encoded zorro transaction
.SH OPTIONS
.HP
\-?
@ -112,13 +112,13 @@ set=NAME:JSON\-STRING
.IP
Set register NAME to given JSON\-STRING
.SH COPYRIGHT
Copyright (C) 2011-2018 The Litecoin Core developers
Copyright (C) 2011-2018 The Zorro Core developers
Copyright (C) 2009-2018 The Bitcoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
Please contribute if you find Zorro Core useful. Visit
<https://cryptogera.com> for further information about the software.
The source code is available from
<https://github.com/litecoin-project/litecoin>.
<https://git.cryptogera.com/cryptogera/zorro>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING

40
doc/man/litecoind.1 → doc/man/zorrod.1
View File

@ -1,13 +1,13 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIND "1" "February 2018" "litecoind v0.15.1.0" "User Commands"
.TH ZORROD "1" "February 2018" "zorrod v0.15.1.0" "User Commands"
.SH NAME
litecoind \- manual page for litecoind v0.15.1.0
zorrod \- manual page for zorrod v0.15.1.0
.SH DESCRIPTION
Litecoin Core Daemon version v0.15.1.0\-dirty
Zorro Core Daemon version v0.15.1.0\-dirty
.SS "Usage:"
.TP
litecoind [options]
Start Litecoin Core Daemon
zorrod [options]
Start Zorro Core Daemon
.SH OPTIONS
.HP
\-?
@ -39,7 +39,7 @@ a0afbded94d4be233e191525dc2d467af5c7eab3143c852c3cd549831022aad6)
.HP
\fB\-conf=\fR<file>
.IP
Specify configuration file (default: litecoin.conf)
Specify configuration file (default: zorro.conf)
.HP
\fB\-daemon\fR
.IP
@ -86,7 +86,7 @@ leave that many cores free, default: 0)
.HP
\fB\-pid=\fR<file>
.IP
Specify pid file (default: litecoin.pid)
Specify pid file (default: zorro.pid)
.HP
\fB\-prune=\fR<n>
.IP
@ -211,7 +211,7 @@ Support filtering of blocks and transaction with bloom filters (default:
.HP
\fB\-port=\fR<port>
.IP
Listen for connections on <port> (default: 9333 or testnet: 19335)
Listen for connections on <port> (default: 18641 or testnet: 19062)
.HP
\fB\-proxy=\fR<ip:port>
.IP
@ -273,12 +273,12 @@ Set key pool size to <n> (default: 1000)
.HP
\fB\-fallbackfee=\fR<amt>
.IP
A fee rate (in LTC/kB) that will be used when fee estimation has
A fee rate (in ZRR/kB) that will be used when fee estimation has
insufficient data (default: 0.02)
.HP
\fB\-discardfee=\fR<amt>
.IP
The fee rate (in LTC/kB) that indicates your tolerance for discarding
The fee rate (in ZRR/kB) that indicates your tolerance for discarding
change by adding it to the fee (default: 0.0001). Note: An output
is discarded if it is dust at this rate, but we will always
discard up to the dust relay fee and a discard fee above that is
@ -286,12 +286,12 @@ limited by the fee estimate for the longest target
.HP
\fB\-mintxfee=\fR<amt>
.IP
Fees (in LTC/kB) smaller than this are considered zero fee for
Fees (in ZRR/kB) smaller than this are considered zero fee for
transaction creation (default: 0.001)
.HP
\fB\-paytxfee=\fR<amt>
.IP
Fee (in LTC/kB) to add to transactions you send (default: 0.00)
Fee (in ZRR/kB) to add to transactions you send (default: 0.00)
.HP
\fB\-rescan\fR
.IP
@ -396,7 +396,7 @@ Prepend debug output with timestamp (default: 1)
.HP
\fB\-maxtxfee=\fR<amt>
.IP
Maximum total fees (in LTC) to use in a single wallet transaction or raw
Maximum total fees (in ZRR) to use in a single wallet transaction or raw
transaction; setting this too low may abort large transactions
(default: 0.10)
.HP
@ -436,7 +436,7 @@ Enable transaction replacement in the memory pool (default: 0)
.HP
\fB\-minrelaytxfee=\fR<amt>
.IP
Fees (in LTC/kB) smaller than this are considered zero fee for relaying,
Fees (in ZRR/kB) smaller than this are considered zero fee for relaying,
mining and transaction creation (default: 0.00001)
.HP
\fB\-whitelistrelay\fR
@ -462,7 +462,7 @@ blockmaxweight
.HP
\fB\-blockmintxfee=\fR<amt>
.IP
Set lowest fee rate (in LTC/kB) for transactions to be included in block
Set lowest fee rate (in ZRR/kB) for transactions to be included in block
creation. (default: 0.00001)
.PP
RPC server options:
@ -507,7 +507,7 @@ option can be specified multiple times
.HP
\fB\-rpcport=\fR<port>
.IP
Listen for JSON\-RPC connections on <port> (default: 9332 or testnet:
Listen for JSON\-RPC connections on <port> (default: 18642 or testnet:
19332)
.HP
\fB\-rpcallowip=\fR<ip>
@ -526,13 +526,13 @@ non\-verbose mode, non\-segwit(0) or segwit(1) (default: 1)
.IP
Set the number of threads to service RPC calls (default: 4)
.SH COPYRIGHT
Copyright (C) 2011-2018 The Litecoin Core developers
Copyright (C) 2011-2018 The Zorro Core developers
Copyright (C) 2009-2018 The Bitcoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
Please contribute if you find Zorro Core useful. Visit
<https://cryptogera.com> for further information about the software.
The source code is available from
<https://github.com/litecoin-project/litecoin>.
<https://git.cryptogera.com/cryptogera/zorro>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING

4
doc/reduce-traffic.md
View File

@ -3,7 +3,7 @@ Reduce Traffic
Some node operators need to deal with bandwidth caps imposed by their ISPs.
By default, litecoin-core allows up to 125 connections to different peers, 8 of
By default, zorro-core allows up to 125 connections to different peers, 8 of
which are outbound. You can therefore, have at most 117 inbound connections.
The default settings can result in relatively significant traffic consumption.
@ -33,5 +33,5 @@ blocks and transactions to fewer nodes.
## 3. Reduce maximum connections (`-maxconnections=<num>`)
Reducing the maximum connected nodes to a minimum could be desirable if traffic
limits are tiny. Keep in mind that litecoin's trustless model works best if you are
limits are tiny. Keep in mind that zorro's trustless model works best if you are
connected to a handful of nodes.

20
doc/release-notes-litecoin.md
View File

@ -1,25 +1,25 @@
Litecoin Core version *0.15.1* is now available from:
Zorro Core version *0.15.1* is now available from:
<https://download.litecoin.org/litecoin-0.15.1/>
<https://download.cryptogera.com/zorro-0.15.1/>
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
Please report bugs using the issue tracker at GitHub:
<https://github.com/litecoin-project/litecoin/issues>
<https://git.cryptogera.com/cryptogera/zorro/issues>
To receive security and update notifications, please subscribe to:
<https://groups.google.com/forum/#!forum/litecoin-dev>
<https://groups.google.com/forum/#!forum/zorro-dev>
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/Litecoin-Qt` (on Mac)
or `litecoind`/`litecoin-qt` (on Linux).
installer (on Windows) or just copy over `/Applications/Zorro-Qt` (on Mac)
or `zorrod`/`zorro-qt` (on Linux).
The first time you run version 0.15.0 or higher, your chainstate database will
be converted to a new format, which will take anywhere from a few minutes to
@ -48,10 +48,10 @@ processing the entire blockchain.
Compatibility
==============
Litecoin Core is extensively tested on multiple operating systems using
Zorro Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.
Litecoin Core should also work on most other Unix-like systems but is not
Zorro Core should also work on most other Unix-like systems but is not
frequently tested on them.
@ -61,7 +61,7 @@ Notable changes
Network fork safety enhancements
--------------------------------
A number of changes to the way Litecoin Core deals with peer connections and invalid blocks
A number of changes to the way Zorro Core deals with peer connections and invalid blocks
have been made, as a safety precaution against blockchain forks and misbehaving peers.
- Unrequested blocks with less work than the minimum-chain-work are now no longer processed even
@ -92,7 +92,7 @@ descends from an invalid block is marked as such.
Minimum relay fee lowered
-------------------------
The minimum relay fee `-minrelayfee` has been lowered to 0.01 lites per kB (0.00001 LTC). This is to prepare for dropping the minimum transaction fee to 0.1 lites per kB (0.0001 LTC) in the next release.
The minimum relay fee `-minrelayfee` has been lowered to 0.01 mZRR per kB (0.00001 ZRR). This is to prepare for dropping the minimum transaction fee to 0.1 mZRR per kB (0.0001 ZRR) in the next release.
Mempool replacement disabled by default
---------------------------------------

122
doc/release-process.md
View File

@ -5,7 +5,7 @@ Before every release candidate:
* Update translations (ping wumpus on IRC) see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#synchronising-translations).
* Update manpages, see [gen-manpages.sh](https://github.com/litecoin-project/litecoin/blob/master/contrib/devtools/README.md#gen-manpagessh).
* Update manpages, see [gen-manpages.sh](https://git.cryptogera.com/cryptogera/zorro/blob/master/contrib/devtools/README.md#gen-manpagessh).
Before every minor and major release:
@ -33,12 +33,12 @@ If you're using the automated script (found in [contrib/gitian-build.sh](/contri
Check out the source code in the following directory hierarchy.
cd /path/to/your/toplevel/build
git clone https://github.com/litecoin-project/gitian.sigs.ltc.git
git clone https://github.com/litecoin-project/litecoin-detached-sigs.git
git clone https://github.com/zorro-project/gitian.sigs.ltc.git
git clone https://git.cryptogera.com/cryptogera/zorro-detached-sigs.git
git clone https://github.com/devrandom/gitian-builder.git
git clone https://github.com/litecoin-project/litecoin.git
git clone https://git.cryptogera.com/cryptogera/zorro.git
### Litecoin maintainers/release engineers, suggestion for writing release notes
### Zorro maintainers/release engineers, suggestion for writing release notes
Write release notes. git shortlog helps a lot, for example:
@ -61,7 +61,7 @@ If you're using the automated script (found in [contrib/gitian-build.sh](/contri
Setup Gitian descriptors:
pushd ./litecoin
pushd ./zorro
export SIGNER=(your Gitian key, ie bluematt, sipa, etc)
export VERSION=(new version, e.g. 0.8.0)
git fetch
@ -95,7 +95,7 @@ Create the OS X SDK tarball, see the [OS X readme](README_osx.md) for details, a
By default, Gitian will fetch source files as needed. To cache them ahead of time:
pushd ./gitian-builder
make -C ../litecoin/depends download SOURCES_PATH=`pwd`/cache/common
make -C ../zorro/depends download SOURCES_PATH=`pwd`/cache/common
popd
Only missing files will be fetched, so this is safe to re-run for each build.
@ -103,50 +103,50 @@ Only missing files will be fetched, so this is safe to re-run for each build.
NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from local URLs. For example:
pushd ./gitian-builder
./bin/gbuild --url litecoin=/path/to/litecoin,signature=/path/to/sigs {rest of arguments}
./bin/gbuild --url zorro=/path/to/zorro,signature=/path/to/sigs {rest of arguments}
popd
The gbuild invocations below <b>DO NOT DO THIS</b> by default.
### Build and sign Litecoin Core for Linux, Windows, and OS X:
### Build and sign Zorro Core for Linux, Windows, and OS X:
pushd ./gitian-builder
./bin/gbuild --num-make 2 --memory 3000 --commit litecoin=v${VERSION} ../litecoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-linux.yml
mv build/out/litecoin-*.tar.gz build/out/src/litecoin-*.tar.gz ../
./bin/gbuild --num-make 2 --memory 3000 --commit zorro=v${VERSION} ../zorro/contrib/gitian-descriptors/gitian-linux.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-linux.yml
mv build/out/zorro-*.tar.gz build/out/src/zorro-*.tar.gz ../
./bin/gbuild --num-make 2 --memory 3000 --commit litecoin=v${VERSION} ../litecoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-win.yml
mv build/out/litecoin-*-win-unsigned.tar.gz inputs/litecoin-win-unsigned.tar.gz
mv build/out/litecoin-*.zip build/out/litecoin-*.exe ../
./bin/gbuild --num-make 2 --memory 3000 --commit zorro=v${VERSION} ../zorro/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-win.yml
mv build/out/zorro-*-win-unsigned.tar.gz inputs/zorro-win-unsigned.tar.gz
mv build/out/zorro-*.zip build/out/zorro-*.exe ../
./bin/gbuild --num-make 2 --memory 3000 --commit litecoin=v${VERSION} ../litecoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-osx.yml
mv build/out/litecoin-*-osx-unsigned.tar.gz inputs/litecoin-osx-unsigned.tar.gz
mv build/out/litecoin-*.tar.gz build/out/litecoin-*.dmg ../
./bin/gbuild --num-make 2 --memory 3000 --commit zorro=v${VERSION} ../zorro/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-osx.yml
mv build/out/zorro-*-osx-unsigned.tar.gz inputs/zorro-osx-unsigned.tar.gz
mv build/out/zorro-*.tar.gz build/out/zorro-*.dmg ../
popd
Build output expected:
1. source tarball (`litecoin-${VERSION}.tar.gz`)
2. linux 32-bit and 64-bit dist tarballs (`litecoin-${VERSION}-linux[32|64].tar.gz`)
3. windows 32-bit and 64-bit unsigned installers and dist zips (`litecoin-${VERSION}-win[32|64]-setup-unsigned.exe`, `litecoin-${VERSION}-win[32|64].zip`)
4. OS X unsigned installer and dist tarball (`litecoin-${VERSION}-osx-unsigned.dmg`, `litecoin-${VERSION}-osx64.tar.gz`)
1. source tarball (`zorro-${VERSION}.tar.gz`)
2. linux 32-bit and 64-bit dist tarballs (`zorro-${VERSION}-linux[32|64].tar.gz`)
3. windows 32-bit and 64-bit unsigned installers and dist zips (`zorro-${VERSION}-win[32|64]-setup-unsigned.exe`, `zorro-${VERSION}-win[32|64].zip`)
4. OS X unsigned installer and dist tarball (`zorro-${VERSION}-osx-unsigned.dmg`, `zorro-${VERSION}-osx64.tar.gz`)
5. Gitian signatures (in `gitian.sigs.ltc/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/`)
### Verify other gitian builders signatures to your own. (Optional)
Add other gitian builders keys to your gpg keyring, and/or refresh keys.
gpg --import litecoin/contrib/gitian-keys/*.pgp
gpg --import zorro/contrib/gitian-keys/*.pgp
gpg --refresh-keys
Verify the signatures
pushd ./gitian-builder
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-linux ../litecoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-win-unsigned ../litecoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-unsigned ../litecoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-linux ../zorro/contrib/gitian-descriptors/gitian-linux.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-win-unsigned ../zorro/contrib/gitian-descriptors/gitian-win.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-unsigned ../zorro/contrib/gitian-descriptors/gitian-osx.yml
popd
### Next steps:
@ -167,22 +167,22 @@ Codesigner only: Create Windows/OS X detached signatures:
Codesigner only: Sign the osx binary:
transfer litecoin-osx-unsigned.tar.gz to osx for signing
tar xf litecoin-osx-unsigned.tar.gz
transfer zorro-osx-unsigned.tar.gz to osx for signing
tar xf zorro-osx-unsigned.tar.gz
./detached-sig-create.sh -s "Key ID"
Enter the keychain password and authorize the signature
Move signature-osx.tar.gz back to the gitian host
Codesigner only: Sign the windows binaries:
tar xf litecoin-win-unsigned.tar.gz
tar xf zorro-win-unsigned.tar.gz
./detached-sig-create.sh -key /path/to/codesign.key
Enter the passphrase for the key when prompted
signature-win.tar.gz will be created
Codesigner only: Commit the detached codesign payloads:
cd ~/litecoin-detached-sigs
cd ~/zorro-detached-sigs
checkout the appropriate branch for this release series
rm -rf *
tar xf signature-osx.tar.gz
@ -195,25 +195,25 @@ Codesigner only: Commit the detached codesign payloads:
Non-codesigners: wait for Windows/OS X detached signatures:
- Once the Windows/OS X builds each have 3 matching signatures, they will be signed with their respective release keys.
- Detached signatures will then be committed to the [litecoin-detached-sigs](https://github.com/litecoin-project/litecoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
- Detached signatures will then be committed to the [zorro-detached-sigs](https://git.cryptogera.com/cryptogera/zorro-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
Create (and optionally verify) the signed OS X binary:
pushd ./gitian-builder
./bin/gbuild -i --commit signature=v${VERSION} ../litecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-signed --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-signed ../litecoin/contrib/gitian-descriptors/gitian-osx-signer.yml
mv build/out/litecoin-osx-signed.dmg ../litecoin-${VERSION}-osx.dmg
./bin/gbuild -i --commit signature=v${VERSION} ../zorro/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-signed --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-osx-signed ../zorro/contrib/gitian-descriptors/gitian-osx-signer.yml
mv build/out/zorro-osx-signed.dmg ../zorro-${VERSION}-osx.dmg
popd
Create (and optionally verify) the signed Windows binaries:
pushd ./gitian-builder
./bin/gbuild -i --commit signature=v${VERSION} ../litecoin/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-signed --destination ../gitian.sigs.ltc/ ../litecoin/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-win-signed ../litecoin/contrib/gitian-descriptors/gitian-win-signer.yml
mv build/out/litecoin-*win64-setup.exe ../litecoin-${VERSION}-win64-setup.exe
mv build/out/litecoin-*win32-setup.exe ../litecoin-${VERSION}-win32-setup.exe
./bin/gbuild -i --commit signature=v${VERSION} ../zorro/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-signed --destination ../gitian.sigs.ltc/ ../zorro/contrib/gitian-descriptors/gitian-win-signer.yml
./bin/gverify -v -d ../gitian.sigs.ltc/ -r ${VERSION}-win-signed ../zorro/contrib/gitian-descriptors/gitian-win-signer.yml
mv build/out/zorro-*win64-setup.exe ../zorro-${VERSION}-win64-setup.exe
mv build/out/zorro-*win32-setup.exe ../zorro-${VERSION}-win32-setup.exe
popd
Commit your signature for the signed OS X/Windows binaries:
@ -235,23 +235,23 @@ sha256sum * > SHA256SUMS
The list of files should be:
```
litecoin-${VERSION}-aarch64-linux-gnu.tar.gz
litecoin-${VERSION}-arm-linux-gnueabihf.tar.gz
litecoin-${VERSION}-i686-pc-linux-gnu.tar.gz
litecoin-${VERSION}-x86_64-linux-gnu.tar.gz
litecoin-${VERSION}-osx64.tar.gz
litecoin-${VERSION}-osx.dmg
litecoin-${VERSION}.tar.gz
litecoin-${VERSION}-win32-setup.exe
litecoin-${VERSION}-win32.zip
litecoin-${VERSION}-win64-setup.exe
litecoin-${VERSION}-win64.zip
zorro-${VERSION}-aarch64-linux-gnu.tar.gz
zorro-${VERSION}-arm-linux-gnueabihf.tar.gz
zorro-${VERSION}-i686-pc-linux-gnu.tar.gz
zorro-${VERSION}-x86_64-linux-gnu.tar.gz
zorro-${VERSION}-osx64.tar.gz
zorro-${VERSION}-osx.dmg
zorro-${VERSION}.tar.gz
zorro-${VERSION}-win32-setup.exe
zorro-${VERSION}-win32.zip
zorro-${VERSION}-win64-setup.exe
zorro-${VERSION}-win64.zip
```
The `*-debug*` files generated by the gitian build contain debug symbols
for troubleshooting by developers. It is assumed that anyone that is interested
in debugging can run gitian to generate the files for themselves. To avoid
end-user confusion about which file to pick, as well as save storage
space *do not upload these to the litecoin.org server, nor put them in the torrent*.
space *do not upload these to the cryptogera.com server, nor put them in the torrent*.
- GPG-sign it, delete the unsigned file:
```
@ -261,24 +261,24 @@ rm SHA256SUMS
(the digest algorithm is forced to sha256 to avoid confusion of the `Hash:` header that GPG adds with the SHA256 used for the files)
Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spurious/nonsensical entry.
- Upload zips and installers, as well as `SHA256SUMS.asc` from last step, to the litecoin.org server.
- Upload zips and installers, as well as `SHA256SUMS.asc` from last step, to the cryptogera.com server.
```
- Update litecoin.org version
- Update cryptogera.com version
- Announce the release:
- litecoin-dev and litecoin-dev mailing list
- zorro-dev and zorro-dev mailing list
- blog.litecoin.org blog post
- blog.cryptogera.com blog post
- Update title of #litecoin and #litecoin-dev on Freenode IRC
- Update title of #zorro and #zorro-dev on Freenode IRC
- Optionally twitter, reddit /r/Litecoin, ... but this will usually sort out itself
- Optionally twitter, reddit /r/Zorro, ... but this will usually sort out itself
- Archive release notes for the new version to `doc/release-notes/` (branch `master` and branch of the release)
- Create a [new GitHub release](https://github.com/litecoin-project/litecoin/releases/new) with a link to the archived release notes.
- Create a [new GitHub release](https://git.cryptogera.com/cryptogera/zorro/releases/new) with a link to the archived release notes.
- Celebrate

48
doc/tor.md
View File

@ -1,16 +1,16 @@
TOR SUPPORT IN LITECOIN
TOR SUPPORT IN ZORRO
======================
It is possible to run Litecoin as a Tor hidden service, and connect to such services.
It is possible to run Zorro 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 litecoin behind a Tor proxy
1. Run zorro behind a Tor proxy
---------------------------------
The first step is running Litecoin behind a Tor proxy. This will already make all
The first step is running Zorro 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
@ -31,27 +31,27 @@ outgoing connections be anonymized, but more is possible.
In a typical situation, this suffices to run behind a Tor proxy:
./litecoin -proxy=127.0.0.1:9050
./zorro -proxy=127.0.0.1:9050
2. Run a litecoin hidden server
2. Run a zorro 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/litecoin-service/
HiddenServicePort 9333 127.0.0.1:9333
HiddenServicePort 19335 127.0.0.1:19335
HiddenServiceDir /var/lib/tor/zorro-service/
HiddenServicePort 18641 127.0.0.1:18641
HiddenServicePort 19062 127.0.0.1:19062
The directory can be different of course, but (both) port numbers should be equal to
your litecoind's P2P listen port (9333 by default).
your zorrod's P2P listen port (18641 by default).
-externalip=X You can tell litecoin about its publicly reachable address using
-externalip=X You can tell zorro 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/litecoin-service/hostname. Onion addresses are given
/var/lib/tor/zorro-service/hostname. Onion addresses are given
preference for your node to advertise itself with, for connections
coming from unroutable addresses (such as 127.0.0.1, where the
Tor proxy typically runs).
@ -68,49 +68,49 @@ your litecoind's P2P listen port (9333 by default).
In a typical situation, where you're only reachable via Tor, this should suffice:
./litecoind -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen
./zorrod -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.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:
./litecoind ... -bind=127.0.0.1
./zorrod ... -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:
./litecoind ... -discover
./zorrod ... -discover
and open port 9333 on your firewall (or use -upnp).
and open port 18641 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:
./litecoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover
./zorro -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.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.
Litecoin Core has been updated to make use of this.
Zorro Core has been updated to make use of this.
This means that if Tor is running (and proper authentication has been configured),
Litecoin Core automatically creates a hidden service to listen on. This will positively
Zorro Core automatically creates a hidden service to listen on. This will positively
affect the number of available .onion nodes.
This new feature is enabled by default if Litecoin Core is listening (`-listen`), and
This new feature is enabled by default if Zorro Core 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 litecoind must have write access
configured. For cookie authentication the user running zorrod 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 litecoind to the same group and setting permissions appropriately. On
Debian-based systems the user running litecoind can be added to the debian-tor group,
the user running zorrod to the same group and setting permissions appropriately. On
Debian-based systems the user running zorrod 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.
@ -118,7 +118,7 @@ Tor configuration.
4. Privacy recommendations
---------------------------
- Do not add anything but litecoin ports to the hidden service created in section 2.
- Do not add anything but zorro ports to the hidden service created in section 2.
If you run a web service too, create a new hidden service for that.
Otherwise it is trivial to link them, which may reduce privacy. Hidden
services created automatically (as in section 3) always have only one port

2
doc/travis-ci.md
View File

@ -32,7 +32,7 @@ trigger cache-invalidation and rebuilds as necessary.
These caches can be manually removed if necessary. This is one of the very few
manual operations that is possible with Travis, and it can be done by the
Litecoin Core committer via the Travis web interface.
Zorro Core committer via the Travis web interface.
In some cases, secure strings may be needed for hiding sensitive info such as
private keys or URLs. The travis client may be used to create these strings:

20
doc/zmq.md
View File

@ -5,8 +5,8 @@ connections, inter-process communication, and shared-memory,
providing various message-oriented semantics such as publish/subscribe,
request/reply, and push/pull.
The Litecoin Core daemon can be configured to act as a trusted "border
router", implementing the litecoin wire protocol and relay, making
The Zorro Core daemon can be configured to act as a trusted "border
router", implementing the zorro 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
@ -33,7 +33,7 @@ buffering or reassembly.
## Prerequisites
The ZeroMQ feature in Litecoin Core requires ZeroMQ API version 4.x or
The ZeroMQ feature in Zorro Core requires ZeroMQ API version 4.x or
newer. Typically, it is packaged by distributions as something like
*libzmq3-dev*. The C++ wrapper for ZeroMQ is *not* needed.
@ -45,7 +45,7 @@ operation.
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 litecoind:
during the *configure* step of building zorrod:
$ ./configure --disable-zmq (other options)
@ -66,8 +66,8 @@ address. The same address can be used in more than one notification.
For instance:
$ litecoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
-zmqpubrawtx=ipc:///tmp/litecoind.tx.raw
$ zorrod -zmqpubhashtx=tcp://127.0.0.1:28332 \
-zmqpubrawtx=ipc:///tmp/zorrod.tx.raw
Each PUB notification has a topic and body, where the header
corresponds to the notification type. For instance, for the
@ -75,7 +75,7 @@ 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 litecoin.conf.
These options can also be provided in zorro.conf.
ZeroMQ endpoint specifiers for TCP (and others) are documented in the
[ZeroMQ API](http://api.zeromq.org/4-0:_start).
@ -87,9 +87,9 @@ arriving. Please see `contrib/zmq/zmq_sub.py` for a working example.
## Remarks
From the perspective of litecoind, the ZeroMQ socket is write-only; PUB
From the perspective of zorrod, the ZeroMQ socket is write-only; PUB
sockets don't even have a read function. Thus, there is no state
introduced into litecoind directly. Furthermore, no information is
introduced into zorrod 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
@ -102,5 +102,5 @@ 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 your are
using. Litecoind appends an up-counting sequence number to each
using. Zorrod appends an up-counting sequence number to each
notification which allows listeners to detect lost notifications.

BIN
share/pixmaps/bitcoin.ico
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 88 KiB

After

Width:  |  Height:  |  Size: 8.8 KiB

BIN
share/pixmaps/bitcoin128.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 13 KiB

439
share/pixmaps/bitcoin128.xpm
View File

@ -1,225 +1,222 @@
/* XPM */
static char *bitcoin___[] = {
static char *result[] = {
/* columns rows colors chars-per-pixel */
"128 128 91 1",
" c #353634",
". c #373836",
"X c #383937",
"o c #3D3E3C",
"O c #3F403E",
"+ c #40413F",
"@ c #434442",
"# c #474847",
"$ c #484947",
"% c #4B4C4B",
"& c #4F504E",
"* c #50514F",
"= c #4F5150",
"- c #545553",
"; c #575857",
": c #585957",
"> c #575858",
", c #5B5C5B",
"< c #5F605E",
"1 c #60615F",
"2 c #5F6160",
"3 c #646464",
"4 c #676867",
"5 c #686967",
"6 c #6B6C6B",
"7 c #6F706F",
"8 c #6F7070",
"9 c #717372",
"0 c #777877",
"q c #7B7C7B",
"w c #80807F",
"e c #7F8080",
"r c #838484",
"t c #888987",
"y c #878888",
"u c #8B8B8B",
"i c #8F908F",
"p c #90908F",
"a c #8D8E90",
"s c #8F9092",
"d c #949595",
"f c #979896",
"g c #989897",
"h c #959698",
"j c #979899",
"k c #9A9B9C",
"l c #9FA09F",
"z c #9E9FA1",
"x c #9FA0A1",
"c c #A3A4A4",
"v c #A7A8A7",
"b c #A6A7A9",
"n c #A7A8A8",
"m c #ACADAD",
"M c #ADAFB1",
"N c #AFB0B3",
"B c #B3B4B6",
"V c #B7B8B7",
"C c #B6B7BA",
"Z c #B7B8BB",
"A c #BABABD",
"S c #BFC0BF",
"D c #BDBEC1",
"F c #BFC0C2",
"G c #C2C3C4",
"H c #C5C6C9",
"J c #C7C8CA",
"K c #CACBCC",
"L c #CECED1",
"P c #CFD0D1",
"I c #D3D4D4",
"U c #D6D6D8",
"Y c #D7D8D9",
"T c #DBDBDC",
"R c #E0DFDF",
"E c #E0E0DF",
"W c #DFDFE0",
"Q c #DFE0E0",
"! c #E3E4E4",
"~ c #E7E7E8",
"^ c #E7E8E8",
"/ c #EBEBEC",
"( c #EFEFF0",
") c #F0EFF0",
"_ c #EFF0F0",
"` c #F4F5F5",
"' c #F6F7F8",
"] c #F8F7F8",
"[ c #F7F8F8",
"{ c #FDFDFD",
"} c None",
"128 128 88 1 ",
" c #000001",
". c #00000C",
"X c #000016",
"o c #00001B",
"O c #000023",
"+ c #00002C",
"@ c #000132",
"# c #000D36",
"$ c #001037",
"% c #021539",
"& c #06183A",
"* c #0C1B3B",
"= c #121E3D",
"- c #16213E",
"; c #18233F",
": c #1A2441",
"> c #1F2943",
", c #232B44",
"< c #282F46",
"1 c #2A3047",
"2 c #2E3449",
"3 c #31364B",
"4 c #353A4D",
"5 c #383D4F",
"6 c #3A3E50",
"7 c #3E4353",
"8 c #424656",
"9 c #444857",
"0 c #464A59",
"q c #4A4E5C",
"w c #4E515E",
"e c #515461",
"r c #565965",
"t c #585B67",
"y c #5B5E69",
"u c #5E616B",
"i c #61646E",
"p c #646771",
"a c #666872",
"s c #6A6C75",
"d c #6D6F78",
"f c #6F7179",
"g c #72747C",
"h c #777980",
"j c #7B7D84",
"k c #7F8087",
"l c #7F8188",
"z c #83848B",
"x c #87888E",
"c c #88898F",
"v c #8B8D92",
"b c #8F9096",
"n c #909196",
"m c #94959A",
"M c #97989D",
"N c #999A9F",
"B c #9C9DA2",
"V c #A1A2A6",
"C c #A4A5A9",
"Z c #A7A8AC",
"A c #A9AAAE",
"S c #ADAEB1",
"D c #AFB0B3",
"F c #B2B3B6",
"G c #B5B6B9",
"H c #B7B8BB",
"J c #B9BABD",
"K c #BDBEC1",
"L c #BFC0C2",
"P c #C2C2C5",
"I c #C6C6C9",
"U c #C7C8CA",
"Y c #CACACC",
"T c #CECFD0",
"R c #CFD0D2",
"E c #D3D3D5",
"W c #D7D7D8",
"Q c #D7D8D9",
"! c #DCDCDD",
"~ c #DFDFE0",
"^ c #DFE0E1",
"/ c #E3E4E5",
"( c #E7E7E8",
") c #ECECED",
"_ c #EFEFF0",
"` c #F4F4F4",
"' c #FFFFFF",
"] c None",
/* pixels */
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} . X . ..}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} XoooooOoOooooooOoooooX }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}ooooooooOooooooooooooooooooOoooX}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}XoOoooOOoOooooooooooooooooOooooOoooooX}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}.ooooooooooooooOoooOooOooOOooooOooooooOooooX}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} o@oOOooooooooooooooooooooOoOooooooooooooooooooOX }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}XoooooooooooooooooOooooooXXXXXXoooooooooooOoOOoOoooooX}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}XoOoooooooooooooooXXo+@%*--:,,:;-&%#ooo.oooooooOoooOooooO }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} ooooooooooOoooo o*5rcVKT!~~^^^^~!!TKVcr5*o ooooooooooooooo }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}oooooooooooooo #5gST`'[{{[[{[[[[{[[[[{{{`_TAg6#. XoooooooooooOo}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} ooooooooooooXo$9nI`[{['][[][[[[[[]][[[[[[[[[{{[)Un9%Xooooooooooooo }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}oooOooOooooo o,kI`{{['['[[[][[[[[[[[[[[[[[[[[][[[]{{'Ik,X oooooooooOOo}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}XoOooooooooooo6B^'{'''[[[[[[{[[[{[{[{[{[{{[[{[][]][[][[{[^B6oooOoooooooooX}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}oooooooooooo@9D`[[[[[{[''{][{'[{{[['{[{{[{[[{[{[{][{''[[[[[{`A9@oooooooOoooX}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}oOoooooooooo4A`{]'[[[[[{'{]{'{]{{[{{{{{]{{{{{{{[{[{{]{[{[[[[''{_A4ooooooooOooo}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}ooooooooooo-c/['[[[[]][['{[{{{{{{[{{{{{{{{{{{{{{{[{[{{[]['[[[[''[{^c-ooooooooooo}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}OooooooooooqY][''[[[['{{][{{[{{{{{{{{{{{{{{{{{{{{{{{{{[{{{{{'{[[[['{[IqooOoooooOoo}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}ooooooOoo %m`'''['[{][{{{{{{{{{{{{{[`/~QQW!!~~/']{{{{{{{{{{{{][[[['''[[`m% oooooOooo}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}ooooooooo.5I[''[[['{[{[{[{{{{{{{(!YKGDACCDCBBCCZAGJU!`'{{{{{{[{{{[{{][[]]]I5.ooooooooo}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}oooooooooot^{'[[[['{[[{{{{{{{'~YHZBBBBCCCCCCCCCCCCVBBBCG!{{{{{{{{{{[{'[[[['[^toXoooooooo}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}oooOooooook'['[[[[{{[{{{{{{{/YGCBCCCCCCCCCCCCCCCCCCCBBALW`{{{{{{{{{{{{[{[{[{[['kooooOoooOo}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}oOooooooo$m][]{']]{{{{{{{{'~LNBBCCCCCCBCCCCCCCCCCCCVZJT`{{{{{{{{{{{{{{{{[{{]][[[]N$ooooooooO}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}ooooooooo%V[[[[['{['{]{]{{~LDNDCCCCZDDDDDDCDDCDDCDDGT/{{{{{{{{{{{{{{{{{{{{[[{[[[[[]Z%ooooooooo}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}ooooooooo%A{[[[[]{]{{{{{{(LDCCDMCZCCMzhzkkkkhzzzhzcCSGHGHGHGGGG){{{{{{{{{{{{{][][[[[]A%XoooooOoX}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}} ooooOooo$Z[][[[[]{{[{{{'YDNCCCDNCCCDeXooooooooXoOOOO++++OO+++O$Y{{{{{{{{{{{{{{{{{[[[]{Z$ooooooo+ }}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}oooooooooM'''[[{[]{{{{{(HBCCCNDNDDBCC3Xooooooooooooooooooooooo 3){{{{{{{{/){{{{{]{[[[][{mOoooooOoo}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}oooooooook'''{{[[{{{{{'WDNCCDCDNDNBBDM%oOoooooooooooooooooooOOo p{{{{{{`WJAAW{{{{{{[{[[][[loooOooooo}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}oooo@oooot'['[[['{{{{{]UCBDCCBCNDNDBDDhooOyVVVVBBVVCZZZZZZZVVwoooA{{{'!LABBCCCI]{{{{[[[{[[['uXoooooooX}}}}}}}}}}}}}",
"}}}}}}}}}}}}}ooooooo 5^[[[''{{[{{{'LBBBDCCCCDNDNDNDq.O#P{{{{{{{{{{{{{{{{{{rXo*E[/YGCBCCCCCCCL]{{{{{[[][[[^5 oooOooo}}}}}}}}}}}}}",
"}}}}}}}}}}}}oooooooX%I[[[[[{[{{{{`JBCCCZCCCCCCCBCGI5Xo3/{{{{{{{{{{{{{{{{{^>oX6WHCBBCCCCCCZCZBJ`{{{[{][[[[{I%oooooooo}}}}}}}}}}}}",
"}}}}}}}}}}} ooooooo+m[[[[[{[{{{{`HBCCCCCZCCCCBDL~[E%oXr{{{{{{{{{{{{{{{{{{H@OXqCNCCCCCCCCCCCCZBJ'{{{{{[]{[[[moooooooo }}}}}}}}}}}",
"}}}}}}}}}}}oOoooooow`][{]{[{{{{`JBCCCCCCCCBZJW`{{{ZoooB{{{{{{{{{{{{{{{{{{cXoOhDBCCCDCCCCCZZCCCBJ'{{{{[{][''`rXooooooo}}}}}}}}}}}",
"}}}}}}}}}}oooooooo-T[][[[[{{{{]LCZCCCCCCAHY({{{{{{p.o$I{{{{{{{{{{{{{{{{{]0Xo%MDBCCCCCCCCCCCCCZCNK{{{{{[{[''{T-oooooooo}}}}}}}}}}",
"}}}}}}}}}}OooOoooon{'[]]{[{[{{UBCCCCBCGI/[{{{{{{{`4Xo5`{{{{{{{{{{{{{{{{{~:o.3DBBDCCCCCCDCCZCBCDL~{{{{{[['[[[{noooooooo}}}}}}}}}}",
"}}}}}}}}}XooooooX6^['[[{{{{{{WBCCCBDL!'{{{{{{{{{{Y$o.u{{{{{{{{{{{{{{{{{{G@oXeDBDBCCCCCCCZBBDJ!`{{{{{{{{{{'[[[^5ooOoooo.}}}}}}}}}",
"}}}}}}}}}ooooooo@D{'[[{[{{{{/ACBCHW){{{{{{{{{{{{{mXooZ{{{{{{{{{{{{{{{{{{goo+zDCCCCCDCCBBZHY({{{{{{{{{]{{{[[[[{A@ooooOoo}}}}}}}}}",
"}}}}}}}} ooooooo9`'''{[[[{{'HBGU(]{{{{{{{{{{{{{{[r o*R{{{{{{{{{{{{{{{{{'0Xo-BACCCDBBBBDI^[{{{{{{{{{{{{{{{[{['[`9ooooooo }}}}}}}}",
"}}}}}}}}ooooooo+F{'[[[{{{{{!K~[{{{{{{{{{{{{{{{{{/:XX7`{{{{{{{{{{{{{{{{{!-oX6AZCCCNBAKW'{{{{{{{{{{{{{{{{{{[[[''{Foooooooo}}}}}}}}",
"}}}}}}}}oooOoO 7`[[[[[[{{{{[{{{{{{{{{{{{{{{{{{{{K+OXg{{{{{{{{{{{{{{{{{{A+ootACBBCHT`{{{{{{{{{{{{{{{{{{{{{{[{{[[`8 oooooO}}}}}}}}",
"}}}}}}}ooOooooXV{[[[{[{{{{{{{{{{{{{{{{{{{{{{{{{{c ooG{{{{{{{{{{{{{{{{{{dXo@xZBDI~[{{{{{{{{{{{{{{{{{{{{{{{{{{[['{CooooOOoo}}}}}}}",
"}}}}}}}Oooooo.3/[[[[[{{{{{{{{{{{{{{{{{{{{{{{{{{`9Xo-!{{{{{{{{{{{{{{{{{`5Xo:CL!'{{{{{{{{{{{{{{{{{{{{{{{{{{{{[[''{^1ooooooo}}}}}}}",
"}}}}}} OOooooXl{[[{{[{{{{{{{{{{{{{{{{{{{{{{{[^IC%o 9[{{{{{{{{{{{{{{{{{T$oXt){{{{{{{{{{{{{{{{{{{{{{{{{^!{{{{][{[[{lXoooooo }}}}}}",
"}}}}}}Xoooooo$Y[][[[{{{{{{{{{{{{{{{{{{{{{{(YHAAd+o k{{{{{{{{{{{{{{{{{{VoooV{{{{{{`{{{{{{{{{{{{{{{{(TJAC~{{{{[][[[U$oooOooo}}}}}}",
"}}}}}}Ooooo+.9'']][{{{{{{{{{{{{{{{{{{{{`WJABCCA0oo@K{{{{{{{{{{{{{{{{{[y o&T{{{/Grc{{{{{{{{{{{{{`!KDBCCBL{{{]{[{[''0 oOoooo}}}}}}",
"}}}}}}oOoooo m{'{[[[]{{{{{{{{{{{{{{{'~KACCCCCCB2oo:^{{{{{{{{{{{{{{{{{`,oX6']Il3@.V{{{{{{{{{{[^UDCBCCCCCZ/{{{{[]]'{m oooooo}}}}}}",
"}}}}}.oooooo#T[[[{{[{{{{{{{{{{{{{[/IFCCCZCCCCAb%o r[{{{{{{{{{{{{{{{{{I$oorB9$oXo&T{{{{{{{[(TGDBCCCCZCCCBU{{{{{]{[[T#ooooooX}}}}}",
"}}}}}oooooo 6`[[[[]{{{{{{{{{{{{)THCBBCCCCCCZCDaoooM{{{{{{{{{{{{{{{{{{mooo@o oooX8`{{{{{)!HCBCCBCCZCCCCCCG]{{[[{[[[`6 ooooOo}}}}}",
"}}}}}+oOooo g[[[[]{{{{{{{{{{'!KACCCCZCCCCZCCCA0oo#I{{{{{{{{{{{{{{{{{{e oooooooood{{{[~PDBBCCCCCCZCCCCCCCZ^{{{{[[[[[g ooOoo+}}}}}",
"}}}}}oooooooS{[[{{{[{{{{{[/PFCBCCCCCCCCCCCZCCB>o.3({{{{{{{{{{{{{{{{{^:ooooo$-oo+F{/YGCVCCCCCACCCZCZCCZCCBU{{{{{[['{Sooooooo}}}}}",
"}}}} oooooo-R[[[{[{{{{{(THBBCCCZCACZCCCCCCCCZc@OXu{{{{{{{{{{{{{{{{{{K@oo@4kI0 o&HLCBCCZCCCCCCACCCZCCCCCCBH]{{{{][[[R-XooOoo }}}}",
"}}}}oooooo 5`[[[][{[{'LABCCCCZCCCCCCCZCZCCCCAuOoXZ{{{{{{{{{{{{{{{{{{g -tG`{/-oo,CBCCCCCCCCCCCCCCCCCZCCCBAP[{{[[{{[[)5Xoooooo}}}}",
"}}}}ooooooXt''[{[{{{{!BCCCCZCCCCCCCCCZCCCCCCZ9Xo%T{{{{{{{{{{{{{{{{{{cn!{{{{G@oXqDCCCCCCCCCCCCCCACCCCCAHT`{{{{{[{[[[]rXoooooo}}}}",
"}}}}oOoooooc['[[]{{{{IBCZCCCCCZCCCZCCCCZCBAJK<oX6]{{{{{{{{{{{{{{{{{{[{{{{{{z.ookDCZCZCCCCACCCCCCCBCGY/[{{{{{{{{[[[[{cooooooo}}}}",
"}}}}oOoooooZ{[[[{[{{{KBCCCCCCCCCCZCCCCBBDP~{I%o d{{{{{{{{{{{{{{{{{{{{{{{{{'0Xo$NACCCCZCCCCCCCCBCDL~'{{{{{{{{{{{{{[[{V+oo+ooO}}}}",
"}}}XooooOo$K[[[{[{{{]DBCCCCCZCZCCCCCCAK!`{{{mooOG{{{{{{{{{{{{{{{{{{{{{{{{{!-o.4ACZCCCCCCCCCCCAJW`{{{{{{{{{{{{{[{[][{K@oooooo }}}",
"}}} Oooooo%T{[[[[{{{`DCCCCZCCCCCBBCHT`{{{{{{rXo;~{{{{{{{{{{{{{{{{{{{{{{{{{G+oXrDCCCCCCZCCBCGY/{{{{{{{{{{{{{{{{{[[[][T%oooo+o.}}}",
"}}}.oooOoX*![[[[[{{{(ZCCZZCCZCBBDI~{{{{{{{{!:oX0'{{{{{{{{{{{{{{{{{{{{{{{{{dXo@zZCCCCZCCBDL~[{{{{{{{{{{{{{{{{{{{{{[]]!*Xooooo }}}",
"}}} oooooo-![][{{{{{^CCCCCCBCDL!`{{{{{{{[Tc3oooc{{{{{{{{{{{{{{{{{{{{{{{`Ja%oo-BCCCCBVZJ!`{{{{{{{{{{{{{{{{{{{{[{{{[[{!*oOoooO.}}}",
"}}}XoooooX-~[][[[{{{~CCCBCZHT({{{{{{{{EB0$XXoo@K{{{{{{{{{{{{{{{{{{{{'Yc6@ ooX6DCBBCHY`[{{{{{{{{{{{{{{{{{{{{{{{{[][[]~-XoOooo }}}",
"}}} oooOoo;![{[{{{{{!BBCGU/{{{{{{{{{!t-oooooo@9/{{{{{{{{{{{{{{{{{{~B0%oXoooo@aCCGI^[{{{{{{{{{{{{{{{{{{{{{{{{{{{{{[[{~-oooooo.}}}",
"}}} OooooX;~[[[[[{{{!DP~'{{{{{{{{{{{g ooo o,uG){{{{{{{{{{{{{{{{{{T:o oooo@,exDL!'{{{{{{{{{{{{{{{{{{{{{{{{'~`{{{{[[[[~;XOoooo }}}",
"}}} oOoooX-~[[[{[{{{''{{{{{{{{{{{{{`7ooo%qV^{{{{{{{{{{{{{{{{{{{{{n.oooo-8dBK!`{{{{{{{{{{{{{{{{{{{{{{{{[/YGC!{{{[{[[{~-XoooooX}}}",
"}}} oooooo-~[[[[{{{{{{{{{{{{{{{{{{{R-oo9T[{{{{{{{{{{{{{{{{{{{{{{{rooO4aMGY/{{{{{{{{{{{{{{{{{{{{{{{{{`THACCB!{{{{][[[~-ooooOo }}}",
"}}}.oooOoo-![[[{[{{{{{{{{{{{{{{{{{{ZoooV{{{{{{{{{{{{{{{{{{{{{{{{/,oX,GY^'{{{{{{{{{{{{{{{{{{{{{{{{'!KDBVCCCB~{{{[{['{!-.oooOo }}}",
"}}} oOoooo-!{[[[[{{{{{{{{{{{{{{{{{{u.o%U{{{{{{{{{{{{{{{{{{{{{{{{K@o u'{{{{{{{{{{{{{{{{{{{{{{{{[~IFCBCCCCCCC/{{{{{[['!*oooooo }}}",
"}}}.oooooo%E[[[{{{{{{{{{{{{{{{{{{{`3XX5`{{{{{{{{{{{{{{{{{{{{{{{{voooG{{{{{{{{{{{{{{{{{{{{{{{(YGCCCCZCCCCCCD({{{{''[[Q&oooooO.}}}",
"}}} oOoOoo$I[[[[[{{{{{{{{{{{{{{{{'G#o.d{{{{{{{{{{{{{{{{{{{{{{{{[qoo*!{{{{{{{{{{{{{{{{{{{{'QKABCCCCCCCCCCCCD`{{[[{['{I$ooOooo }}}",
"}}}}oooooX@G{[[[]{{{{{{{{{{{{{`!KGroooA{{{{{[{{{{{{{{{{{{{{{{{{^,o 9]{{{{{{{{{{{{{{{{{'~IDCBCCCCCCZCZCCCCBH[{{{{[[[{G@oooooo}}}}",
"}}}}ooOooooB{[[{[{]{{{{{{{{[/UDCCZ5oo-!{{'YkV{{{{{{{{{{{{{{{{{{G#o.c{{{{{{{{{{{{{{{{/TGCBCCCCCCCCCCCCCCCCBP{{{[{[[[{Booooooo}}}}",
"}}}}oooooOXg[[[[{{{{{{{{{(THDBCCZM-o 9`!B0%oV{{{{{{{{{{{{{{{{{{cXo+K{{{{{{{{{{{{{)WKDBBBCCCCCCCCCCCCCCCCCBT{{{{][[[[g.ooOooo}}}}",
"}}}}ooooooX0'[[[[]{{{{`!KDCBCCCCDk@oo9y>ooX*T{{{{{{{{{{{{{{{{{'9Xo1){{{{{{{{{{[^PGACCCDZDAAAAAAAAZZCCCCCCB~{{{[{[{[`0ooooooo}}}}",
"}}}}XoooooX1/][{{[{[{'GVCCZCCCCCAeooOoXoOoX6'{{{{{{{{{{{{{{{{{!-OX7GJJGJJHKKGBcddhhhhhhhdddhhhdhhMACCCCAHT{{{][{[[[/3.oooooX}}}}",
"}}}} ooOOoX$I][]]{{{{{JBZCCCCCCCC3oooOooo+.d{{{{{{{{{{{{{{{{{{A+O++@@#@@#@@@@+o@o@@o@@O@@+@O@@@o#cZBBGI/[{{{{{{][[]I@ooooOo.}}}}",
"}}}}}ooooooXB{[[['{{{{WBCCCCCCCAM$oooX@@oooG{{{{{{{{{{{{{{{{{[d oOOooooooooooooooooooooooooooooo>MAK~'{{{{{{{{[{[[{Booooooo}}}}}",
"}}}}}OOooo+ r[[[{{]{{{(ACCCCCCCAho.o=9h3Xo*!{{{{{{{{{{{{{{{{{`4 XXXXooXoooXoo.Xooo.ooXooo.Xoooo.qW`{{{{{{{{{[{{[{[[r oooooO}}}}}",
"}}}}}ooooOoX,/['''[{{{{HBCCCZCCD9o3aMKL-o 0[{{{{{{{{{{{{{{{{{'FVVVVVVVVVBBCVVVVBVVVVBVVVVCBCro+XC{{{{{{{{{{{{{[{[]^,.oooooo}}}}}",
"}}}}}Xoooooo+J{'[[{[{{{WCZCZCCACscGY~]FOo c{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{tXo$T{{{{{{{{{{{{[[[[{JOoOoooO }}}}}",
"}}}}}}oooooo d[[[[{[{{{'DBCCCCBAI~`{{{gXo@K{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{^3o 6'{{{{{{{{{{{{[{[[{d oooooo}}}}}}",
"}}}}}}ooooooX3/['{'{[{{{YBCBAHT){{{{{]7Xo,/{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{I$o d{{{{{{{{{{[{{{[[[/1.ooOooo}}}}}}",
"}}}}}}Xoooooo@G{[[[{{{[{)DGU/{{{{{{{{T%o r[{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{noooG{{{{{{{{{{{]['[[{G+OoOOoOX}}}}}}",
"}}}}}}}oOooOo t[[[[[[{{{{)'{{{{{{{{{{Vo+.n{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{[woX-~{{{{{{{{{{{{{[[][r oooooo}}}}}}}",
"}}}}}}}ooooooo%T{''[{[{{{{{{{{{{{{{{{dXo@I{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{^,oX0[{{{{{{{{{{{[[[[[T%XOooooo}}}}}}}",
"}}}}}}}oooOooo g{[[[]{[{{{{{{{{{{{{{`5X.<`{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{G@oon{{{{{{{{{{{[{{[[{g OooooOo}}}}}}}",
"}}}}}}}}oOooooX-~['][{[{{{{{{{{{{{{{U%O y{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{kXo#K{{{{'){{{{{{][[[~-XOooooO}}}}}}}}",
"}}}}}}}}ooooooooc[[''{[{{{{{{{{{{{{{B+oXV{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{]9.o,/{[^IG~{{{[{[][[[cXOooOooX}}}}}}}}",
"}}}}}}}}}ooOooOo,![[]{[{{{{{{{{{{{{{uXo$T{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{!-XXr(WJZBI{{{{[{[[[[!:o+ooooo}}}}}}}}}",
"}}}}}}}}}ooooooook[[[[{[[{{{{{{{{{{!3oX5/''[[][[[[[[[['[[[[[[][][[[[[[]][][[[[]][[[[[[[[[A+ooaGBBVH'{{{{{[[[[{koooooooo}}}}}}}}}",
"}}}}}}}}}}ooooooo*I[[[[{{{{{{{{{[~Ic#oo-9989899998799989999899978999997789999897899989879,oo@cZCCD/{{{{]{[[[[I-ooooO+o}}}}}}}}}}",
"}}}}}}}}}}oooooooor'[[[[[[{{{{{YGCZroOooX......X....XX..X..X..XX...X.XXX...X..XX...XX...XXoo>BZCA~{{{{[{][[[`r.ooooooo}}}}}}}}}}",
"}}}}}}}}}}}ooooooo@Z{[[[{{{{[{{TBBZ5 oooXoooooXooXoooXXXoo.XoXXXo.XoXXXoo.XoXXXoooooXoooXoo 9ACCW{{{{{[[]{[{Z@ooooooo}}}}}}}}}}}",
"}}}}}}}}}}}OOooOoOo,W[[[][{[{{{{TCB8,2,,<<,<<<<<3,,,379777977779799797977997799953<<<,1,112,jCCT{{{{{][{][[E,oooooOoO}}}}}}}}}}}",
"}}}}}}}}}}}}Ooooooo r`'[]{]{{{{{{YBBCCCCVCCBCCBBBCJT/`''`''`''''''`'`'`''''`])!IFCCCVCCCVVVBCCT{{{{[{{][][`rXooOooo+}}}}}}}}}}}}",
"}}}}}}}}}}}}.Oooooooon{'][[][{{{{{TCCVCZZVZZCBVFI/{{{{{{{{{{{{{{{{{{{{{{{{{)TGAVCCVZVZCZCZCCZW{{{{{{[[]{[]mooooooooX}}}}}}}}}}}}",
"}}}}}}}}}}}}}ooooOoOo#J{'[[{{{{{{{{WABCCCBBBAL~[{{{{{{{{{{{{{{{{{{{{{{{{`!KDBCCCCZZCCZCZZCBD!{{{{{{]{[['{J$oooooooo}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}Oooooooo,R['[[[[{[{{{{~DBBBDHW'{{{{{{{{{{{{{{{{{{{{{{{{'~UDCBCCCZCCCCCCCCCCBF/{{{{{][{'''{W,XOoooOo+}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}Xooooooo.6^[[['{[{{[{{{(KFU({{{{{{{{{{{{{{{{{{{{{{{{{/THBNCCCCCCCZCZCZZCCCCL){{{{][{][[[[~8 oooooooo}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}OooOoooo w/[['[[[{]{{{{{'{{{{{{{{{{{{{{{{{{{{{{{{`!KABCDBCCCCCCCZCCCCCCCDW]{{{{{{{]][[{/q ooOooooo}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}oOoOoooooy({'[[[{[{{{{{{{{{{{{{{{{{{{{{{{{{{{`~PGCCCCDBBCCCCCCCCZZZCCZL/{{{{[{{{[[[[[/tooooooooo}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}Oooooooooy/{'[['{]{{{{{{{{{{{{{{{{{{{{{{{{/YHZCBCCCCCBDCCCCCCCCCBBZJ~{{{{{{{{][[[[{`tooooooooO}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}XooOoooooor/['[{''{'{{{{{{{{{{{{{{{{{{{(WHDBCCCCZCCCCBDCCDBCCCCBCJ!]{{{{{{][{]{[[[^rooooooooo.}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}.oooOooooo0!{[[[]'{[[{{{{{{{{{{{{{{'!LDBBCCCCCCCCCCCCCCCCCCCBZL~]{{{{]{{]{{[[[[{!0oooooooooo}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}XOooooooo 4I{[[[[[{{{]{{{{{{{{{{`PABBCCCCCCZCCZCCCCCCCBBBDGY({{{{{{{][{[{[[[[{Y4 oooOoooOX}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}ooooooooo.-A[{[[[[[[{{[{{{{{{{{(TLFZCBBBBBCBCBCBBBBBZFLW({{{{{{[{{{{{[[[[[[[A- ooOoooooo}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}ooooooooO.@g/['[[[{][[{[{{{{{{{{{'(!YIKGFDDDDDHKIWQ)'{{{{{{{{{{{{]][{[[[[/g@Xooooooooo}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}.oooOoooooX6I[[[[['{]{{[[{[{{{{{{{{{{{{]]`''][{{{{{{{{{{{]]{]{[]{[[[[[[I9.ooooooooo.}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}.ooooooOooX=c^{[['[[{{{[{{{{{{{{{{{{{{{{{{{{{{{{{{{][[{{{[{{[][[[][{^c%XooooooOoo.}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}oOooooooOooo6S`[']''[[]{{[[{{[[{{{{{{{{{{{{{{{]{{{{{{{]{{[[[[[[[[`S6oooooooOoooo}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}} ooooooooooX@wK'{[[[[[[][{{[[{{]{]{][{{{{{{{{{{[{]{[{{[[[{]''{'Kw@XoooOoooooo }}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}oOooOooooooX#wJ`{[[[[[[[[{]{]{{{[{{{]{][{[[{'{'{'{'[[[[[[[`Jr$XoooOooooooo}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}.oooooooooOooO9V/[{'[[[[[[{[[[{]{[{['{[[{[[[[[[[[[[''{[/Z9+Xooooooooooo.}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}} ooooOoOooooo o,jL`{{][[[[[][[[[[[][[[[[[[[[{[[[{[{`Kg,o ooooOooOoOoo }}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}oooooooOoooooX.@4gH~[{[{[[[[[[[]][[[[[[[][{{['^Jk5# ooooooOooooooo}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} Ooooooooooooooo O;qcGT/`[{{{{{{{{{{{{]'/TGc0:o .oooooooooooooo }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}XooooooooooooOOXX .O&30icmmBBBVVBmmcu03&oX XoooOooooooooooo.}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}ooooooooo+ooooOOooX..XX.oooOooooXXXXXooO+ooooooooooooOoo}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}ooooooooooXOXOooooooOoooooooooooooooooooooOooooooooo}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} XooooOoOooOoOooOooOoooooooooooOooooOoooooooooo }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}XooooOooooooooooOoooOooOooooOooooooOoooOoX}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}XoOOoooOOoOoooooooOoooOooooo+oooo+o }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} .oOoooooooOooooooooooooooooX }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} XoOooooOooooOooooX }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} . .. . }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}",
"}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}"
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;:::,;----->;;,;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;;;;;--;;=;----;==-;;;;;;::]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;;=;;;=;;----;=;---------;;;==;;;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;;;-;;;==;;=----=;----------;==;;;=;=;;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;;=;;------;;;=--------------------==;;------;;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;;;;=;=------;==;--------------------;;;=------;-;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;--==;;=-----;-=-;;--------------------;==;--------;;=;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;=;--;;;=;-----=;;-;=------------------;=;;=;--------;=;;;;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;--------------------------------------------=;--------------;;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;-;--------------------------------------------=;;=--------------;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;;;=--------------------------------------------;-----------------;;;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]:;=;=;=---------------------------;=---------------------------------==;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]];-;;=;------------=;--------------------------------------------------;=;=;;]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]];--=;;=----------------------------------------------------------------;;;=--;]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]];;;;-=;;=--------------------------------------------------------;=------==;;----:]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]];;;==;;=;;------------------=;-------------------;=-------------;=;-------;;=;----;;]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]];;=;;----------=;----------;==;;=;;=;;==;;=--------;;=;;==;=;;=;;=;----------------;=;]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]--;;;=-----------------------;;=;;==;;=;;;=;--------=;;=;;:==;;==;=;;=--------------;;;;]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]:----==;-----------------------;;=;;;;=;;;==;-------==;;;=;=:;=;;;;;=----------------=;;;:]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]];;----;;=;----------------------=;;==;;=+XX#;;-------;;=;:#XXO=;=;==;;----------------;==;;;]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]];=;=;---------------;;=------------;;===@mIFq@;;;&&&&&&&&&+wHYm#==;;-------------------;;=;-=;]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]];;;;=;---------------=;-------------=;;;OF'''/0$=@23232323<e('''GO;;=;------------------=;;=---;]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]];;;;=;;=-----------------------------;=:#w`''''SX+V)))))))))`''''`e#=--------------------;=;=----:]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]];;;==;;=;---------------------------;=;=;@i`''''HX+/'''''''''''''''s+------------------------;----;;]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]];=------------------------;;;=;==;-------*=!''''zO+!'`EEWEWWEW''''~=*=----------------------------=;]]]]]]]]]]]]]]",
"]]]]]]]]]]]]];=;------------------------==;;;;;=--------@u(''Z+=+~'(XXOOoOo.V_`!p@=;------------------=---------;;;]]]]]]]]]]]]]",
"]]]]]]]]]]]];=;;----------------;-=;----;=;===;;--------; H'`7#=+~'(%*--=;;=O5r#+;;;----=-------------;---;;----;==;]]]]]]]]]]]]",
"]]]]]]]]]]]:;;;=----------------=;;=----;;:@o+o&--------;XH'`q#=@!'/%*-;;=;;;$#*;;;=----;----------------;==----=;;;:]]]]]]]]]]]",
"]]]]]]]]]]];----------------=---;=;;;;;==;+sT!G<XOOOOO*;;XH'`q#=+~'(%*;;;=;;=;;;=;;-----------------------------;;;=;]]]]]]]]]]]",
"]]]]]]]]]];;----------------;---;==;==;;;@y`'''Evmmmmc4&;XH'`q$=+!'/&*;;;;=;;=+XX+=;=---------------------------;==;;;]]]]]]]]]]",
"]]]]]]]]]:----------------------;;;;;=;=;XF'''''''''''PO;XH'`w$-@~'/%*;*+@@@++vYUj+;;;--------------------------;;;;=;:]]]]]]]]]",
"]]]]]]]]];--------;=------------=;==;;;=;XH'''''''''''/@-XJ'`q#=+~'(%=*,pssauZ''''z+;=-------------------------;==;=;;;]]]]]]]]]",
"]]]]]]]]:;=;==;-------------=;;----------+d`'''Wvvvv('/+=XJ'`w#=+~'/%=OJ'''``'''''EO=-------=-----------------=;-------;]]]]]]]]",
"]]]]]]]];=;;;;----------------=;--------;;+z!)P4XOO !'!@=XJ'`q$-@!'(%&@/''''''''''!O--------;-----------------;;--------]]]]]]]]",
"]]]]]]];;;==-------;--------------------==;++;O%;==+!'/+=XK'`w#=+~'(&&@/')ZZZE''''VO--------;=-----------------=--------;]]]]]]]",
"]]]]]]];;=;;-------=--------------------;;;==*;;;;=@TTz#;+z/`w#;+^'Q@=&unm.XX&K`_F@=---------;--------------------------;]]]]]]]",
"]]]]]];=------=;----------------------------;;=;=;=;3O+:-;+$c7&=@QH2&;;@O+;;;&O94O=;---------------;--------------------;;]]]]]]",
"]]]]]];;------=;----------------------------=;;=;;;;&=+XoOXOO=;=>yOOXOOXO&;;=;=$%;-----------------=--------------------;;]]]]]]",
"]]]]]:;;------;---------------------------;-=;;=;==:++gFEWPb<+:;:O+lJEWKv<O;=;;=----;-------------;;-----------------;--=;:]]]]]",
"]]]]];;=----------------------------=;----=;;=;;;=:OsW''''''/jO;+eE''''''/vX=;=;----=-------------=------------------=--=;;]]]]]",
"]]]];------=;-----------=;;=---;;;;==;;=--------;;Oz`''''`'''`v u)'''`'''''FO==;--=;;;=;=;----=;-------------------;----;;;;]]]]",
"]]]];-------------------;;=;---:==;;;;=;---;----;+s`''(Burz!''`j~'')NyyxW'''BO:=--;==;;=;;----;;-------------------=----;==;]]]]",
"]]]];;------------------=;=;--;+XX+;;==;---=----=@!''Y;X@@O@Y''`''!9X@@OOA''`w#:-;;;----;=;&oXO*------;;----------;;----==;;]]]]",
"]]];=-------------------=;;;=;+gJJs+;;;=------;# g''/&@;;;;@<('''`y+;;;;&.P''A X+==;----;;#3VPN;&----;*%=---------=-----;;=;:]]]",
"]]];------------------=-;;=;;+z`''`h+;;;;=;;-&X0v!''BX;-;--;XB'''T.-;;=;;+u`')FZd+O;----;&:Q'''I+=;;;+#5O@;;;;----------=;;=;]]]",
"]]];------------------;-;==;=+!''''WO;=;;;=;@;S`''''s+------&2E`)vO-=;;=;&2_''''`!zO&---;Oc'''''g+=:+j~`Er@;;=-------;--;;=;;]]]",
"]]:;--------------------;;;;*=(''''/@=;==;;@7!''''''l+------;$$93@;-----;$6`'''''''H#%--;OB'''''v+;@p`'''!:&==;-----;==;=;=;;:]]",
"]];;-------------------;==;=;OP''''Fo=;;=;$1!'''EY''P ------;==$&;------;Oz''!nK)'''I+*-;@i`'''`0$;XA'''''s@;;=;----;=;;=;;;=:]]",
"]];;==;;---;-----------------%<E''Y:*;--;=OP''`c.7`'`k+;;=;;=;;;;;=;;;==&</''z .5J'''Do:=;+m`'`z+;;oC'''''p+;;;=-------------;]]",
"]]=;;;;=---=------------------Xn''gO;;--:+g`''z.;XS'')6%;=;==;=;=;;==;;;$7`'W@=;#XF''`f+:==X!'/O=;=#w)'''T@===;;--------------]]",
"]:;==;=;----------------------oM''j+;;--;oU''J.;;&#Y'(3&=;;;;;===;;=;=;=;@zF9#;==*XI''YO=;=+/'~#=;;;+f`'E=%;;=;=-;----------=;:]",
"]:;;;;=;----------------------OM''j+***-$7_'`t@;=;$,zy#;;;===;;;;=;;;=;;;;+X$;;;;;@y`'`q#;+ !'/#==;;$9`'H.;=;;;=-=----------;;:]",
"];--=-----------------------=;OM''jO**=;+h''WO=;--;&+@;;---;=:=;;==;;=:=;;-;;=;;=;-oE''z++NY`'/#*;=;#w`'JX;;;=;;--------=;;=;;;]",
"];--;-----------------------;;OM'')(((R%oM''KX;=-;;-;;-;:%+@@+@;;;;=;$++++&;=;;=;;;XF''CoXT'''/@=;--#w`'JX;=;=;=--------;=;;=;;]",
"];----------------------------OM''''''D+.B''GX;;--------&9ggggu%=;;;&wgfgg5*=;;=;=;oV''CoOP`)_Z+----#q`'KX;==;;;--------;==;;=;]",
"];----------------------------$9Y~!!~Mo@,R''PX=;--------oP''`')9#;=;XH'''`z+;;=;=;;XK''MO;1332@;----#q`'JX=;;;==--------;;;=;;;]",
":;;=;;==;;=;--------;=;-@@*;=;;%O+++++@w~'''Ao;=----;;=#0`'''''BO==:XH''''z+;;=;;;*$/''SX;*&&&=:--:=#w`'JX::=:=;--------=;-----;",
":;;;=;;;=;----------;;&+yp=@::;=:====$<!'''D*=;;----=;;oB''''''QO=:=XH''''zO;;;==;=+T'''No;;*OXXXXXX 3`'KX==:=;;--------;=----;:",
":==;;=;=----------=;;*$K`'!r XXXXX&::OP''`x.&;------;==+Q''''''`p@:=XH''''z+=;;=;=;$4E''`f@$ePUUYIYIUY''JX;===:=------------;;;:",
":;;=;=;;---------;=;;OV''''(PIIIUIy#+g'''v.;--------;;+p`'')!'''FX=:XG''''z+;;=;;=;;@*W''Q+&%!''''''''''JX;;=:=;------------=;;;",
":;;=;;;=-------------XY''''''''''`6%oI''J.;=;-=;-----;XF'''PB'''(;&;XH''''zO----;=;;:+q`''j+Ov`````````_j+:=--------;;=;;=;;;;=;",
",=;=;=;=------------;XK'''''`````IO&,)'`y@;=--;;----;&,('''mr`'''l+;XG''''z+----=;;==;.H''KX--0qq00qq0q5@;=:--------=;;=;;==;==,",
",=;;==;;=-----------;@y)'''M7wqqe5*@y`'(#=;;---=-----+z'''`qo~'''PX;XH''''z+----=;;=;;+f''~+-=$#$###$#OX@;=---------=;;==;;;;;=,",
",=;=;;;=;-----------=;+eSHgO#####&:@p''~+=;=---------XY'''!<:J'''`9$XH''''zO----;;=;;=#0`'/#*;-=====&@gMuO;---------;=;;=;=;=;=,",
",=-----;--------=;;==;=#XX+==**=**;#w`'(;&;=;;=;----#q`'''````''''NOXH''''z+;=;=;;=;;=@r`'/@-=@@@+++@P''`BO:=;;;==;=----------=,",
",=-----=--------;;=;;=;;+$*******$&=#/''g+;;==;;---;oB''''''''''''WOXG''''zO;;;;=;;=;;on''EO&<T//~/!/''''`q#=;=;;;;;----------=,",
",=----------------=;;==@A(/(///((^w#XH''RX=;;;;=--;=+!''''''''''''`a G''''z+;==;=;;;=*+!''Vo+g''''''''''''s+;;==;==;--------=;=,",
";;----------------;;=;$9`'''''''''DO@r`''B =;=;=--;@d`'''TmNNmH''''F H''''z+;;=;;=;;*.A'')9$+n~!!!!!/''''`w#=;;;;;=;--------;;=:",
":=;=----------------=;#w`'_!!!~!!/I,=XS''`B+;=;;---XJ''''g OOX4`'''(OH''''zO=---;;;@XA'''Vo:;*+++++O+I''`V+-----=;------;=;;==;;",
",=;;----------------;;#q`'H ++++++#;=*@T'''mO;;=--=&I/~/E3&;;=+J/~~~rB/~~/g+;---=;#0Y'''Y+*;;-======%#jmi+;;----;=------;;==;;=,",
",==;----------------;=#w`'HX=====;==;;#,!''GX;--;=::#+@++*;;;=;++@+@;$@++@&;----;*$!'''I>@OXXXXX+:=;;=+O+;------;;=;----=;;;;;;:",
":;;=----------------;;#w`'HX=;;=;&O++&;XY''z+---=;;=;====;=;;=;=====;=====------;&<)''H++@ZYUUYIj@;;==;;--------=;;=----=;=;==;:",
"];;=;;;=--------=;----#w`'JX;;;;&4I~~z+O!'`r@;--;;=;;=;=;;==;;;=----;==;;;;=;=;=;*&('`q+6E''''''~@==--------------------;=----=]",
"];=;;==;--------------#w`'JX=;=;Ov'''mo+!'`s@;--;=;;-&oo*;;;;=;=-----;;-OX#:=:;;:&,('`wOf``````'(*=;--------------------;;----;]",
"];;;;;;;-------;------#q`'JX;;=;Om''_l+XP''Mo;--;=;=O<ZS2&--==;;--;---=*BFqX*;=;;@y`'(:&,qqqq5!'(&*=--------------------=---=;;]",
"];;===;=-------=-----;#0`'HX=;;=Om''vO:OM''EO---=;=Ov(''Bo--;;;=--=---+g''`V+$;;:XB''To:-#$##XW'/&=;--------------------;---;;;]",
"];--;---=;;-;;;=;;;=-;Os`'P ;=;;Om''vO;#0`''vX;;;=+H'''`z+;;----------@y`'''Y%&;$,/''nO-;----OE'(&*;;;--------;-==;-----=;;;;;;]",
"];------;==;==;;==;;-@y)''`m+;==Ov''vO;;XS''_uX=-OM'''Wh+-;=---;------;@rU'''Do&XK''(,&------.E'/+=;;=--------=-;;------;;===;:]",
"]]=;----;;;;;=;=;=;=:oL''''(-*;=+H''P+*;%,~''_vo.-(''DO+---;-;%OO*-----;@.m`'`5+H'''cO------@i)'`g+;------------------=;=;=;;;]]",
"]];-----=;==;;;=;;=:=XE''''_5%;OB''''DO;:+y)'''WBF''I &;;=-=;%0NM3&-----;= J''Y!'''Jo;----;%4(''')0#----------------;=;;=;;;=;]]",
"]]:;=;-----------=;;;oC''''E+==+!''''(#*;;Oy/'''''''kO------;oY''Ho:;;=;;=+j''''''J#&;=;;=;Oc'''''MO-------;--------;=;;=;=;=;]]",
"]]:;;;----;=------;===$K`'!r@;;O!''''/@=;=;+,S_'''''s@------&3)''^+==;;=;=+g''''(mO%;;=;;==+z'''''nO-------=--------=;;==;;;;:]]",
"]]];;==;------------;;=+ti$@;=;Ov''''VO;;=;;&o7vG/''vO------Ov'''`y@=;;=;;.D''Wx1O;---;=;;;*;~'''(4&----------------=;;=;;==:]]]",
"]]];=;;;------------;===@@*;;;=;Ov!!B+=;=;;=::%O z''WO&----&@!''''S ;;=;;Ow_'`y.&;;----;=;=;@wL/Pt+;----------------;;=;;=;;:]]]",
"]]]:;;;=----------------;;------;+O+O=;=;=;;==:=&:/''HX+&=@.H''`''`i.%&@.e!''YO---------;;===#o+o@:=--------------=;;==;=;;=:]]]",
"]]]];==;-----------------;------;;==;;;=;;===:=;:Oz'''Tg,=eP'''zK'')v6<tZ_''(w@---------=;;;;;;=:;=;--------------;;=;;;;=;;]]]]",
"]]]];;=;------------------------=;;-;=;;=;;;;;;=;;oB'''')(`'''S 4!'''`)`'''(u+;---------;=;==;--;;;=---------------=;;;=;==:]]]]",
"]]]]:;;=------------------------;==;=;;==;=;==;;=:=ov(''''''`Z+=@7E'''''''Yw+;----------;=;;=;--==;;----------------;==;=;=,]]]]",
"]]]]];=;--------------------------;==;;=;=;=;;=;;=;;O5VE((!HtX*;;@@vY/(!HfO@;-------=;==;-------;==;;;=;----------------;;=]]]]]",
"]]]]];;=---------------------------;;=;;;;;=;=--;==;;%oO;:@Xo1,-;;+oo%:+X@=:--------;;;;--------;;;==;;=---------------;;=,]]]]]",
"]]]]]];;--------------------------=;;=;==;;;:@XoO=;:;@@%**-+gT9&;;v3o*&:$OO=;-------;==;---=----=;;;=;;=----------=;--;=;;]]]]]]",
"]]]]]];;--------------------------;=;;;=;==;@yJEB#@@Odd4=;+C``3%=+/(B#:&wmP0%-------;=;;---;----;==;;=;;----------;;=-;==:]]]]]]",
"]]]]]]];----------------------------;=;;;=;#e)'''PraeT'(0#XY')4&=+!'(**XH'`e#;;-+XX@;;;=------------;=;-----=-------;=;;;]]]]]]]",
"]]]]]]];------;=------------------=-;==;=:=XA'''''```''`e#XI')4&=+!'(*=XJ'`q@$%+gJHp+;;=------------=;------;-------;=;=;]]]]]]]",
"]]]]]]]]------;=--;=--------------;-;;;;;=;XJ'''''''''')6$oU'_4&=+!'/=*XJ'`u571m'''`f@;;----------------------------=;;;]]]]]]]]",
"]]]]]]]];------;--------------------=;==;;;+k''''(ASSSSj@:oI'_3%=+!'(**XJ''```_`''''Yo;=----------------------------;;=:]]]]]]]]",
"]]]]]]]]];;;;==;;;=;------------------------+N(`Wt XXXX@:=XU'_4&;+!'(*=XH'''''''''''WO=-----------------------------;;;]]]]]]]]]",
"]]]]]]]]]:;=;;;==;;=------------------------;O19@@:;:==:=;oU'_3&=+!'(**$eLTTYTY/''''Ao;-----------------------------=;:]]]]]]]]]",
"]]]]]]]]]];;=;;;-------;--------------------=;&$==;=;=:=:=XI'_4%=+!'(**;#XXooo 5T``P,&------------------------=-----;;]]]]]]]]]]",
"]]]]]]]]]]];;==;-------=--------------------;;;;=:=;;;=;=:oI')4&=+!'(**=;:--;::#+ye+&;------------------------;-----;]]]]]]]]]]]",
"]]]]]]]]]]]:;;=;------------------------------;OOo+;=;;=;;XI')4%;o!'(@=;=--------@#---------------;=--------------;=:]]]]]]]]]]]",
"]]]]]]]]]]]];=;;------------------------------+mWEzXoOOooO I')4&@9(')w@;;-------;--;------------------------------;;]]]]]]]]]]]]",
"]]]]]]]]]]]]];;=-----------------------------OB''''SBBBBBBN!')4#<!'''/<&------------;-=-----------------------=;--;]]]]]]]]]]]]]",
"]]]]]]]]]]]]]];=----------------------------*#/''''''''''''''`5Oz'''''c+------------=;;-----------------------;=--]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]:;----------------------------*&(''''''''''''''/=Ov'''''mO------------------------------------=;;;;:]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]:-----------------------------OG''''Fjzzzzzzzzw$$0)''')0$----------------;=------------------;==;;]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]];;---------;-----------------*;H))A+O++O+O++O#;-+d!_!g+;------------------------------------;;;:]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]---;=-----=------------------&O1,O==;;-;--;----:@+4@+;;--------------------------------=---=;;]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]];;;=;;------------------------&&------;;------;==&=;=;--------------------------------;;=;=;]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]];=;;=---------------------;--;;------;=------;;=;=;;=--------------------------------;=;;;]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]];;----------------------;=--;-------==;-----=;;==;;=-----------------------------------;]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]];----------------------;=--=;------;;=;----;==;;;=;----------------------------------;]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]:;;==;;=;;=;--------------;=--------------;;=;;---------------------------=;;=;==;;:]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]:=;;;=;;=----------------;---------------=;;==;--------------------------;;=;=;;;;]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]];;==;=;----------------=;------------------=;----------------------------=;;;;]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]];;;;=;-------------------------------;----------------------------------;;=;]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]:=;;=----;;=;-----------------------=------------------------------------:]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]];=;----==;;------------------------------------=;----------=---------;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;;-;;;;;=------------------------------------------------;------;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;==;==;-------------------------------------------------------;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;;==;--------------=;-------------;=;--------;;==;=--;==;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;;;-----------------------------=;;--------=;;;;;;=;;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;------------------------------;=--------;=;===;;;;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]];;----------------------------;=--------;=;;;;;;]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;;;-;;=;----=;=---------;=;;;==;----;;;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]:;;=;;----;;;---------;=;=;;;;--=;;:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]::;;--;;;;=---=;-=;;;==;;;::]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]",
"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]>::;;,---;;=,:::,:]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]"
};

BIN
share/pixmaps/bitcoin16.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 951 B

After

Width:  |  Height:  |  Size: 868 B

Some files were not shown because too many files have changed in this diff Show More