<!-- This issue tracker is only for technical issues related to Litecoin Core.
<!-- This issue tracker is only for technical issues related to Kevacoin Core.
General litecoin questions and/or support requests and are best directed to the [litecointalk.io forums](https://litecointalk.io/).
General kevacoin questions and/or support requests and are best directed to the [litecointalk.io forums](https://litecointalk.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 Kevacoin developers on the #kevacoin-dev Freenode IRC channel or alternatively you can email us at contact@kevacoin.org.
If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->
@ -13,7 +13,7 @@ If the node is "stuck" during sync or giving "block checksum mismatch" errors, p
@@ -13,7 +13,7 @@ If the node is "stuck" during sync or giving "block checksum mismatch" errors, p
<!--- How reliably can you reproduce the issue, what are the steps to do so? -->
<!-- What version of Litecoin Core are you using, where did you get it (website, self-compiled, etc)? -->
<!-- What version of Kevacoin Core are you using, where did you get it (website, self-compiled, etc)? -->
<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->
# Start xvfb if needed, as documented at https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-xvfb-to-Run-Tests-That-Require-a-GUI
- if [ "$NEED_XVFB" = 1 ]; then export DISPLAY=:99.0; /sbin/start-stop-daemon --start --pidfile /tmp/custom_xvfb_99.pid --make-pidfile --background --exec /usr/bin/Xvfb -- :99 -ac; fi
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 contrib/verify-commits/verify-commits.sh; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "kevacoin-project/kevacoin" -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" = "kevacoin-project/kevacoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then contrib/verify-commits/verify-commits.sh; fi
for more information on helping with translations.
If a pull request is not to be considered for merging (yet), please
@ -169,11 +169,11 @@ workload on reviewing.
@@ -169,11 +169,11 @@ workload on reviewing.
"Decision Making" Process
-------------------------
The following applies to code changes to the Litecoin Core project (and related
projects such as libsecp256k1), and is not to be confused with overall Litecoin
The following applies to code changes to the Kevacoin Core project (and related
projects such as libsecp256k1), and is not to be confused with overall Kevacoin
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 Kevacoin 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
@ -191,7 +191,7 @@ In general, all pull requests must:
@@ -191,7 +191,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 Kevacoin 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
@ -232,7 +232,7 @@ higher in terms of discussion and peer review requirements, keeping in mind that
@@ -232,7 +232,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 Kevacoin 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.
Kevacoin is a decentralized open source key-value data store based on the Litecoin (which is in turn based on Bitcoin) cryptocurrency. Kevacoin is largely influenced by Namecoin [https://namecoin.org](https://namecoin.org), even though it serves very different purposes and works very differently.
Kevacoin is a decentralized open source key-value data store based on the Kevacoin (which is in turn based on Bitcoin) cryptocurrency. Kevacoin is largely influenced by Namecoin [https://namecoin.org](https://namecoin.org), even though it serves very different purposes and works very differently.
What does it do?
----------------
@ -19,7 +19,7 @@ What does it do?
@@ -19,7 +19,7 @@ What does it do?
What can it be used for?
------------------------
As a decentralized key-value database, it can be used to store data for all kinds of applications, such as social media, microblogging, public identity information, notary service. Kevacoin has limited support for smart contracts (similar to Bitcoin and Litecoin), but one can still develop decentralized apps (dApps) on Kevacoin. The data is decentralized while the application logic is developed off the blockchain.
As a decentralized key-value database, it can be used to store data for all kinds of applications, such as social media, microblogging, public identity information, notary service. Kevacoin has limited support for smart contracts (similar to Bitcoin and Kevacoin), but one can still develop decentralized apps (dApps) on Kevacoin. The data is decentralized while the application logic is developed off the blockchain.
For more information, as well as an immediately useable, binary version of
the Kevacoin Core software, see [https://kevacoin.org](https://kevacoin.org).
@ -41,7 +41,7 @@ Development Process
@@ -41,7 +41,7 @@ Development Process
-------------------
The `master` branch is regularly built and tested, but is not guaranteed to be
completely stable. [Tags](https://github.com/kevacoin-project/litecoin/tags) are created
completely stable. [Tags](https://github.com/kevacoin-project/kevacoin/tags) are created
regularly to indicate new official, stable release versions of Kevacoin Core.
The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md).
@ -7,7 +7,7 @@ dnl Output: If qt version is auto, set bitcoin_enable_qt to false. Else, exit.
@@ -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; kevacoin-qt frontend will not be built])
@ -13,7 +13,7 @@ Construct a linear, no-fork, best version of the blockchain.
@@ -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 Kevacoin network. This means one can have an always-on kevacoind instance running, and another local kevacoind/kevacoin-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,17 +22,17 @@ Build Tools and Keys
@@ -22,17 +22,17 @@ 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 kevacoind/kevacoin-qt
for Debian-based Linux systems. If you compile kevacoind/kevacoin-qt yourself, there are some useful files here.
Files used during the gitian build process. For more information about gitian, see the [the Bitcoin Core documentation repository](https://github.com/bitcoin-core/docs).
### [Gitian-keys](/contrib/gitian-keys)
PGP keys used for signing Litecoin Core [Gitian release](/doc/release-process.md) results.
PGP keys used for signing Kevacoin Core [Gitian release](/doc/release-process.md) results.
### [MacDeploy](/contrib/macdeploy) ###
Scripts and notes for Mac builds.
Scripts and notes for Mac builds.
### [RPM](/contrib/rpm) ###
RPM spec file for building blitecoin-core on RPM based distributions.
@ -40,11 +40,11 @@ RPM spec file for building blitecoin-core on RPM based distributions.
@@ -40,11 +40,11 @@ RPM spec file for building blitecoin-core on RPM based distributions.
### [Gitian-build](/contrib/gitian-build.sh) ###
Script for running full Gitian builds.
Test and Verify Tools
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 Kevacoin tests.
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 kevacoin, gitian-builder, gitian.sigs.ltc, and kevacoin-detached-sigs.
Arguments:
signer GPG signer to sign each build assert file
@ -38,7 +38,7 @@ version Version number, commit, or branch to build. If building a commit or bra
@@ -38,7 +38,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://github.com/kevacoin-project/kevacoin
-v|--verify Verify the gitian build
-b|--build Do a gitian build
-s|--sign Make signed binaries for Windows and Mac OSX
Construct a linear, no-fork, best version of the Litecoin blockchain. The scripts
Construct a linear, no-fork, best version of the Kevacoin blockchain. The scripts
run using Python 3 but are compatible with Python 2.
## Step 1: Download hash list
@ -21,7 +21,7 @@ standalone hash lists but safe to use with linearize-data.py, which will output
@@ -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 `kevacoind` or `kevacoin-qt -server` will be sufficient.
## Step 2: Copy local block data
@ -39,7 +39,7 @@ will be printed.
@@ -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.
For Snow Leopard (which uses [Python 2.6](http://www.python.org/download/releases/2.6/)), you will need the param_parser package:
sudo easy_install argparse
This script should not be run manually, instead, after building as usual:
@ -11,5 +11,5 @@ This script should not be run manually, instead, after building as usual:
@@ -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 `Kevacoin-Core.dmg`.
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 Kevacoin 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 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 kevacoind instance running, and another local kevacoind/kevacoin-qt instance which connects to this node and receives blocks from it.
@ -19,22 +19,22 @@ if [ -f wallet.dat -a -f peers.dat -a -f chainstate/CURRENT -a -f blocks/index/C
@@ -19,22 +19,22 @@ if [ -f wallet.dat -a -f peers.dat -a -f chainstate/CURRENT -a -f blocks/index/C
This is a system of building and caching dependencies necessary for building Litecoin.
This is a system of building and caching dependencies necessary for building Kevacoin.
There are several features that make it different from most similar systems:
### It is designed to be builder and host agnostic
@ -26,7 +26,7 @@ Before building, a unique build-id is generated for each package. This id
@@ -26,7 +26,7 @@ Before building, a unique build-id is generated for each package. This id
consists of a hash of all files used to build the package (Makefiles, packages,
etc), and as well as a hash of the same data for each recursive dependency. If
any portion of a package's build recipe changes, it will be rebuilt as well as
any other package that depends on it. If any of the main makefiles (Makefile,
any other package that depends on it. If any of the main makefiles (Makefile,
funcs.mk, etc) are changed, all packages will be rebuilt. After building, the
results are cached into a tarball that can be re-used and distributed.
@ -92,6 +92,6 @@ build process to remain somewhat deterministic. Here's how it works:
@@ -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://github.com/kevacoin-project/kevacoin-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.
Litecoin is a free open source peer-to-peer electronic cash system that is
Kevacoin 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.
@@ -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 kevacoin-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;
Kevacoin Core is the original Kevacoin client and it builds the backbone of the network.
However, it downloads and stores the entire history of Kevacoin 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.
@ -100,4 +100,4 @@ Only supports JSON as output format.
@@ -100,4 +100,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 kevacoind 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.
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`,
@ -648,7 +648,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
@@ -648,7 +648,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 `kevacoin-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
@ -667,7 +667,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
@@ -667,7 +667,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*: `kevacoin-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.
@ -689,7 +689,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
@@ -689,7 +689,7 @@ A few guidelines for introducing and reviewing new RPC interfaces:
RPCs whose behavior does *not* depend on the current chainstate may omit this
call.
- *Rationale*: In previous versions of Litecoin Core, the wallet was always
- *Rationale*: In previous versions of Kevacoin Core, the wallet was always
in-sync with the chainstate (by virtue of them all being updated in the
same cs_main lock). In order to maintain the behavior that wallet RPCs
return results as of at least the highest best-known block an RPC
Litecoin Core attempts to minimize the level of trust in DNS seeds,
Kevacoin 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 Kevacoin community.
Other implementations of Litecoin software may also use the same
Other implementations of Kevacoin 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
@@ -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 Kevacoin 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.
@@ -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 Kevacoin
network and must not be retained longer than necessary nor disclosed
to any third party.
@ -42,13 +42,13 @@ details of their operating practices.
@@ -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 Kevacoin
@ -17,15 +17,15 @@ How to Upgrade
@@ -17,15 +17,15 @@ 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/Kevacoin-Qt (on Mac) or
kevacoind/kevacoin-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:
backwards-compatible with pre-0.10 versions of Kevacoin 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
@ -44,14 +44,14 @@ supported and may break as soon as the older version attempts to reindex.
@@ -44,14 +44,14 @@ 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
Kevacoin 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.
is included in as separate release-notes. This section describes the Kevacoin-specific differences.
Protocol:
- Scrypt Proof-of-Work instead of sha256d, however block hashes are sha256d for performance reasons.
- 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)
- Kevacoin 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.
- Kevacoin Core rounds transaction size up to the nearest 1000 bytes before calculating fees. This size rounding behavior is to mimic fee calculation of Kevacoin v0.6 and v0.8.
- Bitcoin's IsDust() is disabled in favor of Kevacoin'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
Notable changes since Kevacoin 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.
- kevacoind no longer sends RPC commands. You must use the separate kevacoin-cli command line utility.
@ -18,15 +18,15 @@ How to Upgrade
@@ -18,15 +18,15 @@ 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/Kevacoin-Qt (on Mac) or
kevacoind/kevacoin-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:
backwards-compatible with pre-0.10 versions of Kevacoin 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
@ -66,13 +66,13 @@ specified point in the future.
@@ -66,13 +66,13 @@ specified point in the future.
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
**Notice to miners:** Kevacoin 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
Kevacoin 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
@ -89,7 +89,7 @@ Windows bug fix for corrupted UTXO database on unclean shutdowns
@@ -89,7 +89,7 @@ Windows bug fix for corrupted UTXO database on unclean shutdowns
ECDSA signatures inside Litecoin transactions now use validation using
ECDSA signatures inside Kevacoin 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
@ -88,15 +88,15 @@ can often prevent an extra roundtrip before the actual block is downloaded.
@@ -88,15 +88,15 @@ 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
Previous versions of Kevacoin 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
for previous versions of Kevacoin Core was to raise the default minimum
relay fee.
Litecoin Core 0.13.2 will have a strict maximum size on the mempool. The
Kevacoin 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
@ -105,7 +105,7 @@ minimum relay feerate will be increased to match this feerate plus the initial
@@ -105,7 +105,7 @@ 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
Kevacoin 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
@ -124,7 +124,7 @@ overridden with the option `-rpccookiefile`.
@@ -124,7 +124,7 @@ overridden with the option `-rpccookiefile`.
This is similar to Tor's CookieAuthentication: see
@ -147,10 +147,10 @@ returned (previously all relevant hashes were returned).
@@ -147,10 +147,10 @@ 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
Kevacoin 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
transactions for mined blocks. Kevacoin Core will relay transactions with
insufficient fees depending on the setting of `-limitfreerelay=<r>` (default:
`r=15` kB per minute) and `-blockprioritysize=<s>`.
@ -175,7 +175,7 @@ Note, however, that if mining priority transactions is left disabled, the
@@ -175,7 +175,7 @@ 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
entirely in Kevacoin 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.
@ -185,15 +185,15 @@ Automatically use Tor hidden services
@@ -185,15 +185,15 @@ 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.
Kevacoin 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
Kevacoin Core automatically creates a hidden service to listen on, without
manual configuration. Kevacoin 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
This new feature is enabled by default if Kevacoin 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`.
@ -214,8 +214,8 @@ Various improvements have been made to how the wallet calculates
@@ -214,8 +214,8 @@ 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
(or `settxfee <n>` rpc during runtime). A value of `n=0` signals Kevacoin
Core to use floating fees. By default, Kevacoin Core will use floating
fees.
Based on past transaction data, floating fees approximate the fees
@ -226,9 +226,9 @@ Sometimes, it is not possible to give good estimates, or an estimate
@@ -226,9 +226,9 @@ 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:
At all times, Kevacoin Core will cap fees at `-maxtxfee=<x>` (default:
0.10) LTC.
Furthermore, Litecoin Core will never create transactions paying less than
Furthermore, Kevacoin 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.
@ -271,7 +271,7 @@ However, rescans as well as the RPCs `importwallet`, `importaddress`,
@@ -271,7 +271,7 @@ 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
`kevacoin.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
@ -330,7 +330,7 @@ and are affected by this change:
@@ -330,7 +330,7 @@ and are affected by this change:
- RPC `decodescript`
- REST `/rest/tx/` (JSON format)
- REST `/rest/block/` (JSON format when including extended tx details)
- `litecoin-tx -json`
- `kevacoin-tx -json`
For example, the `scriptSig.asm` property of a transaction input that
previously showed an assembly representation of:
@ -387,7 +387,7 @@ caching. A sample config for apache2 could look like:
@@ -387,7 +387,7 @@ caching. A sample config for apache2 could look like:
# AuthType Digest
# ...
# optional bypass litecoind rpc basic auth
# optional bypass kevacoind rpc basic auth
# RequestHeader set Authorization "Basic <hash>"
# get the <hash> from the shell with: base64 <<<litecoinrpc:<password>
</Location>
@ -401,7 +401,7 @@ Other P2P Changes
@@ -401,7 +401,7 @@ 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
Restarting kevacoind 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.
@ -415,21 +415,21 @@ For this reason the default was changed to 300 MiB in this release.
@@ -415,21 +415,21 @@ 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
- Adding `dbcache=100` in kevacoin.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
kevacoin-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
$ src/kevacoin-cli -stdin walletpassphrase
mysecretcode
120
..... press Ctrl-D here to end input
@ -443,7 +443,7 @@ table by any user on the system.
@@ -443,7 +443,7 @@ table by any user on the system.
C++11 and Python 3
------------------
Various code modernizations have been done. The Litecoin Core code base has
Various code modernizations have been done. The Kevacoin 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.
[BIP112][] redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV)
for a new opcode in the Litecoin scripting system that in combination with
for a new opcode in the Kevacoin 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.
@ -499,10 +499,10 @@ For more information about the implementation, see
@@ -499,10 +499,10 @@ For more information about the implementation, see
BIP113 locktime enforcement soft fork
-------------------------------------
This release seeks to make mempool-only locktime enforcement using GetMedianTimePast()
This release seeks to make mempool-only locktime enforcement using GetMedianTimePast()
a consensus rule.
Litecoin transactions currently may specify a locktime indicating when
Kevacoin 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.
@ -592,7 +592,7 @@ You can't disable HD key generation once you have created a HD wallet.
@@ -592,7 +592,7 @@ 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.
HD wallets are incompatible with older versions of Kevacoin Core.
@ -645,7 +645,7 @@ files on disk. These two have now been split up, so that all blocks are known
@@ -645,7 +645,7 @@ 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,
The two phases are distinct in the Kevacoin-Qt GUI. During the first one,
"Reindexing blocks on disk" is shown. During the second (slower) one,
- REST `/rest/block/` (JSON format when including extended tx details)
- `litecoin-tx -json`
- `kevacoin-tx -json`
- The sorting of the output of the `getrawmempool` output has changed.
@ -786,9 +786,9 @@ covered by the txid. This provides several immediate benefits:
@@ -786,9 +786,9 @@ covered by the txid. This provides several immediate benefits:
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
malleability, which is a problem that makes programming Kevacoin wallet
software more difficult and which seriously complicates the design of smart
contracts for Litecoin.
contracts for Kevacoin.
- **Capacity increase:** Segwit transactions contain new fields that are not
part of the data currently used to calculate the size of a block, which
@ -802,7 +802,7 @@ covered by the txid. This provides several immediate benefits:
@@ -802,7 +802,7 @@ covered by the txid. This provides several immediate benefits:
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
each Kevacoin 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),
@ -835,7 +835,7 @@ covered by the txid. This provides several immediate benefits:
@@ -835,7 +835,7 @@ covered by the txid. This provides several immediate benefits:
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
- **Increased security for multisig:**Kevacoin 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
@ -845,7 +845,7 @@ covered by the txid. This provides several immediate benefits:
@@ -845,7 +845,7 @@ covered by the txid. This provides several immediate benefits:
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
believed to be provided by Kevacoin's choice of parameters for its Elliptic
Curve Digital Security Algorithm [ECDSA].)
- **More efficient almost-full-node security** Satoshi Nakamoto's original
@ -853,7 +853,7 @@ covered by the txid. This provides several immediate benefits:
@@ -853,7 +853,7 @@ covered by the txid. This provides several immediate benefits:
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),
produce an accurate copy of Kevacoin'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
@ -861,13 +861,13 @@ covered by the txid. This provides several immediate benefits:
@@ -861,13 +861,13 @@ covered by the txid. This provides several immediate benefits:
(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
note that Kevacoin 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
Kevacoin users to individually opt-in to almost any change in the Kevacoin
Script language when those users receive new transactions. Features
currently being researched by Bitcoin and Litecoin Core contributors that may
currently being researched by Bitcoin and Kevacoin 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
@ -877,8 +877,8 @@ covered by the txid. This provides several immediate benefits:
@@ -877,8 +877,8 @@ covered by the txid. This provides several immediate benefits:
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
segwit's start date of 1 January 2017 miners can update the Kevacoin
client to Kevacoin 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
@ -911,7 +911,7 @@ a third-party to insert data into other people's transactions, changing
@@ -911,7 +911,7 @@ 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
Since Kevacoin 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,
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.
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 Kevacoin 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.
@ -64,7 +64,7 @@ Testnet faucets can be located at:
@@ -64,7 +64,7 @@ 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).
Developers who require the new testnet blockchain paramaters can find them [here](https://github.com/kevacoin-project/kevacoin/blob/0.13/src/chainparams.cpp#L214).
Litecoin Core is extensively tested on multiple operating systems using
Kevacoin 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),
@ -24,7 +24,7 @@ No attempt is made to prevent installing or running the software on Windows XP,
@@ -24,7 +24,7 @@ No attempt is made to prevent installing or running the software on Windows XP,
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
Kevacoin Core should also work on most other Unix-like systems but is not
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.
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 Kevacoin 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.
@ -56,7 +56,7 @@ Testnet faucets can be located at:
@@ -56,7 +56,7 @@ 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).
Developers who require the new testnet blockchain paramaters can find them [here](https://github.com/kevacoin-project/kevacoin/blob/master/src/chainparams.cpp#L220).
Performance Improvements
--------------
@ -83,7 +83,7 @@ improved, leading to much shorter sync and initial block download times.
@@ -83,7 +83,7 @@ improved, leading to much shorter sync and initial block download times.
Manual Pruning
--------------
Litecoin Core has supported automatically pruning the blockchain since 0.13.2. Pruning
Kevacoin 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.
@ -124,7 +124,7 @@ ZMQ On Windows
@@ -124,7 +124,7 @@ 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
now ZMQ can be used on Windows. Please see [this document](https://github.com/kevacoin-project/kevacoin/blob/master/doc/zmq.md) for
help with using ZMQ in general.
Nested RPC Commands in Debug Console
@ -136,7 +136,7 @@ command without running the commands separately.
@@ -136,7 +136,7 @@ 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
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
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
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
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
@ -157,7 +157,7 @@ the same thing as the GUI icon. The command takes one boolean parameter,
@@ -157,7 +157,7 @@ the same thing as the GUI icon. The command takes one boolean parameter,
Out-of-sync Modal Info Layer
----------------------------
When Litecoin Core is out-of-sync on startup, a semi-transparent information
When Kevacoin 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
@ -166,19 +166,19 @@ unhidden by clicking on the progress bar at the bottom of the window.
@@ -166,19 +166,19 @@ 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
Commands sent over the JSON-RPC interface and through the `kevacoin-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
`kevacoin-cli` has been updated to support this by parsing `name=value` arguments
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
@ -209,7 +209,7 @@ commands such as `prioritisetransaction` so that those changes will not be lost.
@@ -209,7 +209,7 @@ 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 disabled and deprecated in Kevacoin 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
@ -218,15 +218,15 @@ so that all old nodes receive the final alert.
@@ -218,15 +218,15 @@ 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
- 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
- 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
- UTXO set query (`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>
/.../<txid>-<n>.<bin|hex|json>`) responses were changed to return status
/.../<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.
@ -413,7 +413,7 @@ the same cache performance as prior releases. Users on low-memory systems
@@ -413,7 +413,7 @@ the same cache performance as prior releases. Users on low-memory systems
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:
here, originally written for Bitcoin but can also be used for Kevacoin:
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).
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Kevacoin-Qt` (on Mac)
or `kevacoind`/`kevacoin-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,
@ -48,10 +48,10 @@ processing the entire blockchain.
@@ -48,10 +48,10 @@ processing the entire blockchain.
Compatibility
==============
Litecoin Core is extensively tested on multiple operating systems using
Kevacoin 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
Kevacoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes
@ -92,7 +92,7 @@ Initial Block Download, startup, transaction and block validation much faster:
@@ -92,7 +92,7 @@ Initial Block Download, startup, transaction and block validation much faster:
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.
- Scrypt hashing has been optimized for architectures supporting SSE 2 (See [PR 362](https://github.com/kevacoin-project/kevacoin/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
---------------------------
@ -116,7 +116,7 @@ Fee estimation has been significantly improved in version 0.15, with more accura
@@ -116,7 +116,7 @@ Fee estimation has been significantly improved in version 0.15, with more accura
- 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).
- If Kevacoin 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
@ -135,17 +135,17 @@ In version 0.15, creating an opt-in RBF transaction and replacing the unconfirme
@@ -135,17 +135,17 @@ In version 0.15, creating an opt-in RBF transaction and replacing the unconfirme
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.
Kevacoin 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.
Multi-wallet is enabled by using more than one `-wallet` argument when starting Kevacoin, either on the command line or in the Kevacoin 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.
**In Kevacoin-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:
Kevacoin Core 0.15.0 contains the following changes to the RPC interface and `kevacoin-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`.
* When running Kevacoin Core with a single wallet, there are **no** changes to the RPC interface or `kevacoin-cli`. All RPC calls and `kevacoin-cli` commands continue to work as before.
* When running Kevacoin 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 `kevacoin-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 Kevacoin 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/`. `kevacoin-cli` commands should be run with a `-rpcwallet` option, for example `kevacoin-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.
@ -153,7 +153,7 @@ Note that while multi-wallet is now fully supported, the RPC multi-wallet interf
@@ -153,7 +153,7 @@ Note that while multi-wallet is now fully supported, the RPC multi-wallet interf
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:
In previous versions of Kevacoin 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. Kevacoin 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.
@ -186,7 +186,7 @@ Version 0.15 introduces several new RPC methods:
@@ -186,7 +186,7 @@ Version 0.15 introduces several new RPC methods:
Low-level RPC changes
---------------------
- When using Litecoin Core in multi-wallet mode, RPC requests for wallet methods must specify
- When using Kevacoin 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
A number of changes to the way Litecoin Core deals with peer connections and invalid blocks
A number of changes to the way Kevacoin 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
if they have more work than the tip (a potential issue during IBD where the tip may have low-work).
This prevents peers wasting the resources of a node.
This prevents peers wasting the resources of a node.
- Peers which provide a chain with less work than the minimum-chain-work during IBD will now be disconnected.
@ -255,7 +255,7 @@ Thanks to everyone who directly contributed to this release:
@@ -255,7 +255,7 @@ Thanks to everyone who directly contributed to this release:
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/Kevacoin-Qt` (on Mac)
or `kevacoind`/`kevacoin-qt` (on Linux).
The first time you run version 0.15.0 or newer, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
@ -40,10 +40,10 @@ wallets that were created with older versions are not affected by this.
@@ -40,10 +40,10 @@ wallets that were created with older versions are not affected by this.
Compatibility
==============
Litecoin Core is extensively tested on multiple operating systems using
Kevacoin 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
Kevacoin Core should also work on most other Unix-like systems but is not
@ -5,7 +5,7 @@ Before every release candidate:
@@ -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://github.com/kevacoin-project/kevacoin/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
@@ -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.
### Litecoin maintainers/release engineers, suggestion for writing release notes
### Kevacoin 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
@@ -61,7 +61,7 @@ If you're using the automated script (found in [contrib/gitian-build.sh](/contri
@ -95,7 +95,7 @@ Create the OS X SDK tarball, see the [OS X readme](README_osx.md) for details, a
@@ -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 ../kevacoin/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.
@@ -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 kevacoin=/path/to/kevacoin,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 Kevacoin Core for Linux, Windows, and OS X:
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 (`kevacoin-${VERSION}.tar.gz`)
2. linux 32-bit and 64-bit dist tarballs (`kevacoin-${VERSION}-linux[32|64].tar.gz`)
3. windows 32-bit and 64-bit unsigned installers and dist zips (`kevacoin-${VERSION}-win[32|64]-setup-unsigned.exe`, `kevacoin-${VERSION}-win[32|64].zip`)
4. OS X unsigned installer and dist tarball (`kevacoin-${VERSION}-osx-unsigned.dmg`, `kevacoin-${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.
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 [kevacoin-detached-sigs](https://github.com/kevacoin-project/kevacoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
Create (and optionally verify) the signed OS X binary:
It is possible to run Litecoin as a Tor hidden service, and connect to such services.
It is possible to run Kevacoin 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 kevacoin behind a Tor proxy
---------------------------------
The first step is running Litecoin behind a Tor proxy. This will already make all
The first step is running Kevacoin 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.
@@ -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
./kevacoin -proxy=127.0.0.1:9050
2. Run a litecoin hidden server
2. Run a kevacoin 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/
HiddenServiceDir /var/lib/tor/kevacoin-service/
HiddenServicePort 9333 127.0.0.1:9333
HiddenServicePort 19335 127.0.0.1:19335
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 kevacoind's P2P listen port (9333 by default).
-externalip=X You can tell litecoin about its publicly reachable address using
-externalip=X You can tell kevacoin 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/kevacoin-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,57 +68,57 @@ your litecoind's P2P listen port (9333 by default).
@@ -68,57 +68,57 @@ your litecoind's P2P listen port (9333 by default).
In a typical situation, where you're only reachable via Tor, this should suffice:
@ -102,5 +102,5 @@ retrieve the chain from the last known block to the new tip.
@@ -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. Kevacoind appends an up-counting sequence number to each
using. kevacoind appends an up-counting sequence number to each
notification which allows listeners to detect lost notifications.
This directory contains integration tests that test litecoind and its
This directory contains integration tests that test kevacoind and its
utilities in their entirety. It does not contain unit tests, which
can be found in [/src/test](/src/test), [/src/wallet/test](/src/wallet/test),
etc.
There are currently two sets of tests in this directory:
- [functional](/test/functional) which test the functionality of
litecoind and litecoin-qt by interacting with them through the RPC and P2P
- [functional](/test/functional) which test the functionality of
kevacoind and kevacoin-qt by interacting with them through the RPC and P2P
interfaces.
- [util](/test/util) which tests the litecoin utilities, currently only
litecoin-tx.
- [util](/test/util) which tests the kevacoin utilities, currently only
kevacoin-tx.
The util tests are run as part of `make check` target. The functional
tests are run by the travis continuous build process whenever a pull
@ -70,29 +70,29 @@ options. Run `test_runner.py -h` to see them all.
@@ -70,29 +70,29 @@ options. Run `test_runner.py -h` to see them all.
##### Resource contention
The P2P and RPC ports used by the litecoind nodes-under-test are chosen to make
conflicts with other processes unlikely. However, if there is another litecoind
The P2P and RPC ports used by the kevacoind nodes-under-test are chosen to make
conflicts with other processes unlikely. However, if there is another kevacoind
process running on the system (perhaps from a previous test which hasn't successfully
killed all its litecoind nodes), then there may be a port conflict which will
killed all its kevacoind nodes), then there may be a port conflict which will
cause the test to fail. It is recommended that you run the tests on a system
where no other litecoind processes are running.
where no other kevacoind processes are running.
On linux, the test_framework will warn if there is another
litecoind process running when the tests are started.
kevacoind process running when the tests are started.
If there are zombie litecoind processes after test failure, you can kill them
If there are zombie kevacoind processes after test failure, you can kill them
by running the following commands. **Note that these commands will kill all
litecoind processes running on the system, so should not be used if any non-test
litecoind processes are being run.**
kevacoind processes running on the system, so should not be used if any non-test
kevacoind processes are being run.**
```bash
killall litecoind
killall kevacoind
```
or
```bash
pkill -9 litecoind
pkill -9 kevacoind
```
@ -103,11 +103,11 @@ functional test is run and is stored in test/cache. This speeds up
@@ -103,11 +103,11 @@ functional test is run and is stored in test/cache. This speeds up
test startup times since new blockchains don't need to be generated for
each test. However, the cache may get into a bad state, in which case
tests will fail. If this happens, remove the cache directory (and make
anywhere in the test. You will then be able to inspect variables, as well as
call methods that interact with the litecoind nodes-under-test.
call methods that interact with the kevacoind nodes-under-test.
If further introspection of the litecoind instances themselves becomes
If further introspection of the kevacoind instances themselves becomes
necessary, this can be accomplished by first setting a pdb breakpoint
at an appropriate location, running the test to that point, then using
`gdb` to attach to the process and debug.
@ -169,19 +169,19 @@ For instance, to attach to `self.node[1]` during a run:
@@ -169,19 +169,19 @@ For instance, to attach to `self.node[1]` during a run:
use the directory path to get the pid from the pid file:
@ -74,12 +74,12 @@ over the network (`CBlock`, `CTransaction`, etc, along with the network-level
@@ -74,12 +74,12 @@ over the network (`CBlock`, `CTransaction`, etc, along with the network-level
wrappers for them, `msg_block`, `msg_tx`, etc).
- P2P tests have two threads. One thread handles all network communication
with the litecoind(s) being tested (using python's asyncore package); the other
with the kevacoind(s) being tested (using python's asyncore package); the other
implements the test logic.
- `P2PConnection` is the class used to connect to a litecoind. `P2PInterface`
- `P2PConnection` is the class used to connect to a kevacoind. `P2PInterface`
contains the higher level logic for processing P2P payloads and connecting to
the Litecoin Core node application logic. For custom behaviour, subclass the
the Kevacoin Core node application logic. For custom behaviour, subclass the
P2PInterface object and override the callback methods.
- Call `network_thread_start()` after all `P2PInterface` objects are created to
@ -92,14 +92,14 @@ Examples tests are `p2p_unrequested_blocks.py`, `p2p_compactblocks.py`.
@@ -92,14 +92,14 @@ Examples tests are `p2p_unrequested_blocks.py`, `p2p_compactblocks.py`.
#### Comptool
- Comptool is a Testing framework for writing tests that compare the block/tx acceptance
behavior of a litecoind against 1 or more other litecoind instances. It should not be used
behavior of a kevacoind against 1 or more other kevacoind instances. It should not be used
to write static tests with known outcomes, since that type of test is easier to write and
maintain using the standard BitcoinTestFramework.
- Set the `num_nodes` variable (defined in `ComparisonTestFramework`) to start up
1 or more nodes. If using 1 node, then `--testbinary` can be used as a command line
option to change the litecoind binary used by the test. If using 2 or more nodes,
then `--refbinary` can be optionally used to change the litecoind that will be used
option to change the kevacoind binary used by the test. If using 2 or more nodes,
then `--refbinary` can be optionally used to change the kevacoind that will be used
on nodes 2 and up.
- Implement a (generator) function called `get_tests()` which yields `TestInstance`s.
@ -108,13 +108,13 @@ Each `TestInstance` consists of:
@@ -108,13 +108,13 @@ Each `TestInstance` consists of:
* `object` is a `CBlock`, `CTransaction`, or
`CBlockHeader`. `CBlock`'s and `CTransaction`'s are tested for
acceptance. `CBlockHeader`s can be used so that the test runner can deliver
complete headers-chains when requested from the litecoind, to allow writing
complete headers-chains when requested from the kevacoind, to allow writing
tests where blocks can be delivered out of order but still processed by
headers-first litecoind's.
headers-first kevacoind's.
* `outcome` is `True`, `False`, or `None`. If `True`
or `False`, the tip is compared with the expected tip -- either the
block passed in, or the hash specified as the optional 3rd entry. If
`None` is specified, then the test will compare all the litecoind's
`None` is specified, then the test will compare all the kevacoind's
being tested to see if they all agree on what the best tip is.
* `hash` is the block hash of the tip to compare against. Optional to
specify; if left out then the hash of the block passed in will be used as
@ -128,7 +128,7 @@ Each `TestInstance` consists of:
@@ -128,7 +128,7 @@ Each `TestInstance` consists of:
sequence and synced (this is slower when processing many blocks).
- `sync_every_transaction`: `True/False`. Analogous to
`sync_every_block`, except if the outcome on the last tx is "None",
then the contents of the entire mempool are compared across all litecoind
then the contents of the entire mempool are compared across all kevacoind
connections. If `True` or `False`, then only the last tx's
acceptance is tested against the given outcome.
@ -147,7 +147,7 @@ Base class for functional tests.
@@ -147,7 +147,7 @@ Base class for functional tests.
self.assert_start_raises_init_error(0,['-conf='+conf_file],'Error reading configuration file: specified data directory "'+new_data_dir+'" does not exist.')
print("%sWARNING!%s There is already a litecoind process running on this system. Tests may fail unexpectedly due to resource contention!"%(BOLD[1],BOLD[0]))
print("%sWARNING!%s There is already a kevacoind process running on this system. Tests may fail unexpectedly due to resource contention!"%(BOLD[1],BOLD[0]))
Jianping Wu
6 years ago