<!-- This issue tracker is only for technical issues related to Bitcoin Core.
<!-- This issue tracker is only for technical issues related to Litecoin Core.
General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com.
General litecoin questions and/or support requests and are best directed to the [litecointalk.io forums](https://litecointalk.io/).
For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/.
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.
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 Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->
<!-- What version of Litecoin 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)? -->
The Bitcoin Core project operates an open contributor model where anyone is
The Litecoin 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:
@@ -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 bitcoin-qt
- *Qt* for changes to litecoin-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 bitcoin unit tests or QA tests
- *Tests* for changes to the litecoin 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.
@ -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 Bitcoin Core project (and related
projects such as libsecp256k1), and is not to be confused with overall Bitcoin
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
Network Protocol consensus changes.
Whether a pull request is merged into Bitcoin Core rests with the project merge
Whether a pull request is merged into Litecoin 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 Bitcoin consensus rules are considerably more involved than
Patches that change Litecoin 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 Bitcoin consensus, it must have been
Where a patch set proposes to change the Litecoin 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.
@ -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; bitcoin-qt frontend will not be built])
AC_MSG_WARN([$1; litecoin-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 Bitcoin network. This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-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 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.
### [Seeds](/contrib/seeds) ###
Utility to generate the pnSeed[] array that is compiled into the client.
@ -22,20 +22,20 @@ Build Tools and Keys
@@ -22,20 +22,20 @@ Build Tools and Keys
---------------------
### [Debian](/contrib/debian) ###
Contains files used to package bitcoind/bitcoin-qt
for Debian-based Linux systems. If you compile bitcoind/bitcoin-qt yourself, there are some useful files here.
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.
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 Bitcoin Core [Gitian release](/doc/release-process.md) results.
PGP keys used for signing Litecoin 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 bitcoin-core on RPM based distributions.
RPM spec file for building blitecoin-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
@@ -44,7 +44,7 @@ Test and Verify Tools
---------------------
### [TestGen](/contrib/testgen) ###
Utilities to generate test vectors for the data-driven Bitcoin tests.
Utilities to generate test vectors for the data-driven Litecoin tests.
Construct a linear, no-fork, best version of the Bitcoin blockchain. The scripts
Construct a linear, no-fork, best version of the Litecoin 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:
@@ -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: `8332`)
* RPC: `port` (Default: `9332`)
* 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
@@ -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 `bitcoind` or `bitcoin-qt -server` will be sufficient.
JSON-RPC server. Running `litecoind` or `litecoin-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.
@ -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 `Bitcoin-Core.dmg`.
When finished, it will produce `Litecoin-Core.dmg`.
@ -8,9 +8,9 @@ and remove old versions as necessary (at a minimum when GetDesireableServiceFlag
@@ -8,9 +8,9 @@ and remove old versions as necessary (at a minimum when GetDesireableServiceFlag
changes its default return value, as those are the services which seeds are added
to addrman with).
The seeds compiled into the release are created from sipa's DNS seed data, like this:
The seeds compiled into the release are created from poolers's DNS seed data, like this:
@ -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
Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions (which is currently more than 100 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.
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.
To download Bitcoin Core, visit [bitcoincore.org](https://bitcoincore.org/en/releases/).
To download Litecoin Core, visit [litecoin.org](https://litecoin.org).
Running
---------------------
The following are some helpful notes on how to run Bitcoin on your native platform.
The following are some helpful notes on how to run Litecoin on your native platform.
### Unix
Unpack the files into a directory and run:
- `bin/bitcoin-qt` (GUI) or
- `bin/bitcoind` (headless)
- `bin/litecoin-qt` (GUI) or
- `bin/litecoind` (headless)
### Windows
Unpack the files into a directory, and then run bitcoin-qt.exe.
Unpack the files into a directory, and then run litecoin-qt.exe.
### OS X
Drag Bitcoin-Core to your applications folder, and then run Bitcoin-Core.
Drag Litecoin-Core to your applications folder, and then run Litecoin-Core.
### Need Help?
* See the documentation at the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Main_Page)
* See the documentation at the [Litecoin Wiki](https://litecoin.info/)
for help and more information.
* Ask for help on [#bitcoin](http://webchat.freenode.net?channels=bitcoin) on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net?channels=bitcoin).
* Ask for help on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Technical Support board](https://bitcointalk.org/index.php?board=4.0).
* 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.
Building
---------------------
The following are developer notes on how to build Bitcoin on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
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.
- [Dependencies](dependencies.md)
- [OS X Build Notes](build-osx.md)
@ -46,12 +46,12 @@ The following are developer notes on how to build Bitcoin on your native platfor
@@ -46,12 +46,12 @@ The following are developer notes on how to build Bitcoin on your native platfor
Development
---------------------
The Bitcoin repo's [root README](/README.md) contains relevant information on the development process and automated testing.
The Litecoin repo's [root README](/README.md) contains relevant information on the development process and automated testing.
@ -62,9 +62,8 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
@@ -62,9 +62,8 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
- [Benchmarking](benchmarking.md)
### Resources
* Discuss on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Development & Technical Discussion board](https://bitcointalk.org/index.php?board=6.0).
* Discuss project-specific development on #bitcoin-core-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=bitcoin-core-dev).
* Discuss general Bitcoin development on #bitcoin-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=bitcoin-dev).
* 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).
@ -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/bitcoin-core/bitcoin-detached-sigs).
using the script that is also included there. Detached signatures are available from this [repository](https://github.com/litecoin-project/litecoin-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.
Bitcoin is a free open source peer-to-peer electronic cash system that is
Litecoin 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 bitcoin-qt.exe.
Unpack the files into a directory and run litecoin-qt.exe.
Bitcoin Core is the original Bitcoin client and it builds the backbone of the network.
However, it downloads and stores the entire history of Bitcoin transactions;
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;
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.
The REST API can be enabled with the `-rest` option.
The interface runs on the same port as the JSON-RPC interface, by default port 8332 for mainnet, port 18332 for testnet,
and port 18443 for regtest.
The interface runs on the same port as the JSON-RPC interface, by default port 9332 for mainnet, port 19332 for testnet,
and port 19443 for regtest.
Supported API
-------------
@ -91,7 +91,7 @@ Only supports JSON as output format.
@@ -91,7 +91,7 @@ Only supports JSON as output format.
* bytes : (numeric) size of the TX mempool in bytes
* usage : (numeric) total TX mempool memory usage
* maxmempool : (numeric) maximum memory usage for the mempool in bytes
* mempoolminfee : (numeric) minimum feerate (BTC per KB) for tx to be accepted
* mempoolminfee : (numeric) minimum feerate (LTC per KB) for tx to be accepted
`GET /rest/mempool/contents.json`
@ -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 bitcoind 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 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.
See [dependencies.md](dependencies.md) for a complete overview.
@ -49,7 +49,7 @@ from the root of the repository. Then set `BDB_PREFIX` for the next section:
@@ -49,7 +49,7 @@ from the root of the repository. Then set `BDB_PREFIX` for the next section:
export BDB_PREFIX="$PWD/db4"
```
### Building Bitcoin Core
### Building Litecoin Core
**Important**: use `gmake`, not `make`. The non-GNU `make` will exit with a horrible error.
@ -24,6 +24,10 @@ If you want to build the disk image with `make deploy` (.dmg / optional), you ne
@@ -24,6 +24,10 @@ If you want to build the disk image with `make deploy` (.dmg / optional), you ne
brew install librsvg
If you want to build with ZeroMQ support
brew install zeromq
NOTE: Building with Qt4 is still supported, however, could result in a broken UI. Building with Qt5 is recommended.
Berkeley DB
@ -40,17 +44,17 @@ from the root of the repository.
@@ -40,17 +44,17 @@ from the root of the repository.
**Note**: You only need Berkeley DB if the wallet is enabled (see the section *Disable-Wallet mode* below).
Build Bitcoin Core
Build Litecoin Core
------------------------
1. Clone the bitcoin source code and cd into `bitcoin`
1. Clone the litecoin source code and cd into `litecoin`
C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
memory available when compiling Bitcoin Core. On systems with less, gcc can be
memory available when compiling Litecoin 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
@@ -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 Bitcoin Core without wallet.
See the section "Disable-wallet mode" to build Litecoin Core without wallet.
Optional (see --with-miniupnpc and --enable-upnp-default):
@ -107,7 +107,7 @@ ZMQ dependencies (provides ZMQ API 4.x):
@@ -107,7 +107,7 @@ ZMQ dependencies (provides ZMQ API 4.x):
Dependencies for the GUI: Ubuntu & Debian
-----------------------------------------
If you want to build Bitcoin-Qt, make sure that the required packages for Qt development
If you want to build Litecoin-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:
@@ -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 bitcoin-qt executable will be
Once these are installed, they will be found by configure and a litecoin-qt executable will be
built by default.
Dependency Build Instructions: Fedora
@ -147,7 +147,7 @@ libqrencode (optional) can be installed with:
@@ -147,7 +147,7 @@ libqrencode (optional) can be installed with:
Notes
-----
The release is built with GCC and then "strip bitcoind" to strip the debug
The release is built with GCC and then "strip litecoind" to strip the debug
symbols, which reduces the executable size by about 90%.
@ -188,7 +188,7 @@ If you need to build Boost yourself:
@@ -188,7 +188,7 @@ If you need to build Boost yourself:
Security
--------
To help make your bitcoin installation more secure by making certain attacks impossible to
To help make your litecoin 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:
@ -212,7 +212,7 @@ Hardening enables the following features:
@@ -212,7 +212,7 @@ Hardening enables the following features:
To test that you have built PIE executable, install scanelf, part of paxutils, and use:
scanelf -e ./bitcoin
scanelf -e ./litecoin
The output should contain:
@ -221,13 +221,13 @@ Hardening enables the following features:
@@ -221,13 +221,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, bitcoin should be built with a non-executable stack
vulnerable buffers are found. By default, litecoin 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 ./bitcoin`
`scanelf -e ./litecoin`
the output should contain:
STK/REL/PTL
@ -237,7 +237,7 @@ Hardening enables the following features:
@@ -237,7 +237,7 @@ Hardening enables the following features:
Disable-wallet mode
--------------------
When the intention is to run only a P2P node without a wallet, bitcoin may be compiled in
When the intention is to run only a P2P node without a wallet, litecoin may be compiled in
disable-wallet mode with:
./configure --disable-wallet
@ -259,8 +259,8 @@ Setup and Build Example: Arch Linux
@@ -259,8 +259,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:
Below are some notes on how to build Bitcoin Core for Windows.
Below are some notes on how to build Litecoin Core for Windows.
The options known to work for building Bitcoin Core on Windows are:
The options known to work for building Litecoin 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 Bitcoin Core Windows release binaries.
and is the platform used to build the Litecoin 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
@@ -53,7 +53,7 @@ Cross-compilation for Ubuntu and Windows Subsystem for Linux
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
@@ -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 Bitcoin Core source path MUST be somewhere in the default mount file system, for
example /usr/src/bitcoin, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
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.
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.
@ -153,7 +153,7 @@ to see it.
@@ -153,7 +153,7 @@ to see it.
**testnet and regtest modes**
Run with the -testnet option to run with "play bitcoins" on the test network, if you
Run with the -testnet option to run with "play litecoins" 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.
@ -162,7 +162,7 @@ that run in -regtest mode.
@@ -162,7 +162,7 @@ that run in -regtest mode.
**DEBUG_LOCKORDER**
Bitcoin Core is a multithreaded application, and deadlocks or other multithreading bugs
Litecoin 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.
@ -176,10 +176,10 @@ which includes known Valgrind warnings in our dependencies that cannot be fixed
@@ -176,10 +176,10 @@ which includes known Valgrind warnings in our dependencies that cannot be fixed
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 `bitcoin-cli`, and can be surprising to users.
- *Rationale*: This is impossible to use with `litecoin-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*: `bitcoin-cli` and the GUI debug console use this table to determine how to
- *Rationale*: `litecoin-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 Bitcoin Core, the wallet was always
- *Rationale*: In previous versions of Litecoin 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
Bitcoin Core attempts to minimize the level of trust in DNS seeds,
Litecoin 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 Bitcoin community.
level of trust within the Litecoin community.
Other implementations of Bitcoin software may also use the same
Other implementations of Litecoin 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 Bitcoin nodes from the public network to the best of the
functioning Litecoin 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 Bitcoin
for the operation of the service or urgent health of the Litecoin
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 Bitcoin
discontinue providing services and contact the active Litecoin
@ -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/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagessh).
* Update manpages, see [gen-manpages.sh](https://github.com/litecoin-project/litecoin/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.
### Bitcoin maintainers/release engineers, suggestion for writing release notes
### Litecoin maintainers/release engineers, suggestion for writing release notes
Write release notes. git shortlog helps a lot, for example:
@ -61,16 +61,16 @@ If you're using the automated script (found in [contrib/gitian-build.sh](/contri
@@ -61,16 +61,16 @@ If you're using the automated script (found in [contrib/gitian-build.sh](/contri
Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other Gitian signatures.
Ensure your gitian.sigs.ltc are up-to-date if you wish to gverify your builds against other Gitian signatures.
pushd ./gitian.sigs
pushd ./gitian.sigs.ltc
git pull
popd
@ -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 ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common
make -C ../litecoin/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,62 +103,62 @@ Only missing files will be fetched, so this is safe to re-run for each build.
@@ -103,62 +103,62 @@ 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 bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments}
./bin/gbuild --url litecoin=/path/to/litecoin,signature=/path/to/sigs {rest of arguments}
popd
The gbuild invocations below <b>DO NOT DO THIS</b> by default.
### Build and sign Bitcoin Core for Linux, Windows, and OS X:
### Build and sign Litecoin Core for Linux, Windows, and OS X:
2. linux 32-bit and 64-bit dist tarballs (`bitcoin-${VERSION}-linux[32|64].tar.gz`)
3. windows 32-bit and 64-bit unsigned installers and dist zips (`bitcoin-${VERSION}-win[32|64]-setup-unsigned.exe`, `bitcoin-${VERSION}-win[32|64].zip`)
4. OS X unsigned installer and dist tarball (`bitcoin-${VERSION}-osx-unsigned.dmg`, `bitcoin-${VERSION}-osx64.tar.gz`)
5. Gitian signatures (in `gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/`)
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`)
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 [bitcoin-detached-sigs](https://github.com/bitcoin-core/bitcoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
- 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.
Create (and optionally verify) the signed OS X binary:
It is possible to run Bitcoin as a Tor hidden service, and connect to such services.
It is possible to run Litecoin 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 bitcoin behind a Tor proxy
1. Run litecoin behind a Tor proxy
---------------------------------
The first step is running Bitcoin behind a Tor proxy. This will already make all
The first step is running Litecoin 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:
./bitcoin -proxy=127.0.0.1:9050
./litecoin -proxy=127.0.0.1:9050
2. Run a bitcoin hidden server
2. Run a litecoin 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/bitcoin-service/
HiddenServiceDir /var/lib/tor/litecoin-service/
HiddenServicePort 9333 127.0.0.1:9333
HiddenServicePort 19333 127.0.0.1:19333
HiddenServicePort 19335 127.0.0.1:19335
The directory can be different of course, but (both) port numbers should be equal to
your bitcoind's P2P listen port (9333 by default).
your litecoind's P2P listen port (9333 by default).
-externalip=X You can tell bitcoin about its publicly reachable address using
-externalip=X You can tell litecoin 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/bitcoin-service/hostname. Onion addresses are given
/var/lib/tor/litecoin-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 bitcoind's P2P listen port (9333 by default).
@@ -68,49 +68,49 @@ your bitcoind's P2P listen port (9333 by default).
In a typical situation, where you're only reachable via Tor, this should suffice:
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 bitcoind:
during the *configure* step of building litecoind:
$ ./configure --disable-zmq (other options)
@ -66,8 +66,8 @@ address. The same address can be used in more than one notification.
@@ -66,8 +66,8 @@ address. The same address can be used in more than one notification.
For instance:
$ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
-zmqpubrawtx=ipc:///tmp/bitcoind.tx.raw
$ litecoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
-zmqpubrawtx=ipc:///tmp/litecoind.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
@@ -75,7 +75,7 @@ notification `-zmqpubhashtx` the topic is `hashtx` (no null
terminator) and the body is the transaction hash (32
bytes).
These options can also be provided in bitcoin.conf.
These options can also be provided in litecoin.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.
@@ -87,9 +87,9 @@ arriving. Please see `contrib/zmq/zmq_sub.py` for a working example.
## Remarks
From the perspective of bitcoind, the ZeroMQ socket is write-only; PUB
From the perspective of litecoind, the ZeroMQ socket is write-only; PUB
sockets don't even have a read function. Thus, there is no state
introduced into bitcoind directly. Furthermore, no information is
introduced into litecoind 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.
@@ -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. Bitcoind appends an up-counting sequence number to each
using. Litecoind appends an up-counting sequence number to each
notification which allows listeners to detect lost notifications.
@ -16,14 +16,14 @@ BEGIN
@@ -16,14 +16,14 @@ BEGIN
BEGIN
BLOCK "040904E4" // U.S. English - multilingual (hex)
BEGIN
VALUE "CompanyName", "Bitcoin"
VALUE "FileDescription", "bitcoin-cli (JSON-RPC client for " PACKAGE_NAME ")"
VALUE "CompanyName", "Litecoin"
VALUE "FileDescription", "litecoin-cli (JSON-RPC client for " PACKAGE_NAME ")"
VALUE "FileVersion", VER_FILEVERSION_STR
VALUE "InternalName", "bitcoin-cli"
VALUE "InternalName", "litecoin-cli"
VALUE "LegalCopyright", COPYRIGHT_STR
VALUE "LegalTrademarks1", "Distributed under the MIT software license, see the accompanying file COPYING or http://www.opensource.org/licenses/mit-license.php."
strUsage+=HelpMessageOpt("-rpcclienttimeout=<n>",strprintf(_("Timeout in seconds during HTTP requests, or 0 for no timeout. (default: %d)"),DEFAULT_HTTP_CLIENT_TIMEOUT));
strUsage+=HelpMessageOpt("-stdinrpcpass",strprintf(_("Read RPC password from standard input as a single line. When combined with -stdin, the first line from standard input is used for the RPC password.")));
strUsage+=HelpMessageOpt("-stdin",_("Read extra arguments from standard input, one per line until EOF/Ctrl-D (recommended for sensitive information such as passphrases). When combined with -stdinrpcpass, the first line from standard input is used for the RPC password."));
strUsage+=HelpMessageOpt("-rpcwallet=<walletname>",_("Send RPC for non-default wallet on RPC server (argument is wallet filename in bitcoind directory, required if bitcoind/-Qt runs with multiple wallets)"));
strUsage+=HelpMessageOpt("-rpcwallet=<walletname>",_("Send RPC for non-default wallet on RPC server (argument is wallet filename in litecoind directory, required if litecoind/-Qt runs with multiple wallets)"));
returnstrUsage;
}
@ -86,10 +86,10 @@ static int AppInitRPC(int argc, char* argv[])
@@ -86,10 +86,10 @@ static int AppInitRPC(int argc, char* argv[])
@ -16,14 +16,14 @@ BEGIN
@@ -16,14 +16,14 @@ BEGIN
BEGIN
BLOCK "040904E4" // U.S. English - multilingual (hex)
BEGIN
VALUE "CompanyName", "Bitcoin"
VALUE "FileDescription", "bitcoin-tx (CLI Bitcoin transaction editor utility)"
VALUE "CompanyName", "Litecoin"
VALUE "FileDescription", "litecoin-tx (CLI Litecoin transaction editor utility)"
VALUE "FileVersion", VER_FILEVERSION_STR
VALUE "InternalName", "bitcoin-tx"
VALUE "InternalName", "litecoin-tx"
VALUE "LegalCopyright", COPYRIGHT_STR
VALUE "LegalTrademarks1", "Distributed under the MIT software license, see the accompanying file COPYING or http://www.opensource.org/licenses/mit-license.php."
@ -16,14 +16,14 @@ BEGIN
@@ -16,14 +16,14 @@ BEGIN
BEGIN
BLOCK "040904E4" // U.S. English - multilingual (hex)
BEGIN
VALUE "CompanyName", "Bitcoin"
VALUE "FileDescription", "bitcoind (Bitcoin node with a JSON-RPC server)"
VALUE "CompanyName", "Litecoin"
VALUE "FileDescription", "litecoind (Litecoin node with a JSON-RPC server)"
VALUE "FileVersion", VER_FILEVERSION_STR
VALUE "InternalName", "bitcoind"
VALUE "InternalName", "litecoind"
VALUE "LegalCopyright", COPYRIGHT_STR
VALUE "LegalTrademarks1", "Distributed under the MIT software license, see the accompanying file COPYING or http://www.opensource.org/licenses/mit-license.php."
ui->labelExplanation->setText(tr("These are your Bitcoin addresses for sending payments. Always check the amount and the receiving address before sending coins."));
ui->labelExplanation->setText(tr("These are your Litecoin addresses for sending payments. Always check the amount and the receiving address before sending coins."));
ui->deleteAddress->setVisible(true);
break;
caseReceivingTab:
ui->labelExplanation->setText(tr("These are your Bitcoin addresses for receiving payments. It is recommended to use a new receiving address for each transaction."));
ui->labelExplanation->setText(tr("These are your Litecoin addresses for receiving payments. It is recommended to use a new receiving address for each transaction."));
tr("Warning: If you encrypt your wallet and lose your passphrase, you will <b>LOSE ALL OF YOUR BITCOINS</b>!")+"<br><br>"+tr("Are you sure you wish to encrypt your wallet?"),
tr("Warning: If you encrypt your wallet and lose your passphrase, you will <b>LOSE ALL OF YOUR LITECOINS</b>!")+"<br><br>"+tr("Are you sure you wish to encrypt your wallet?"),
QMessageBox::critical(0,"Runaway exception",BitcoinGUI::tr("A fatal error occurred. Bitcoin can no longer continue safely and will quit.")+QString("\n\n")+message);
QMessageBox::critical(0,"Runaway exception",BitcoinGUI::tr("A fatal error occurred. Litecoin can no longer continue safely and will quit.")+QString("\n\n")+message);
<string>Recent transactions may not yet be visible, and therefore your wallet's balance might be incorrect. This information will be correct once your wallet has finished synchronizing with the bitcoin network, as detailed below.</string>
<string>Recent transactions may not yet be visible, and therefore your wallet's balance might be incorrect. This information will be correct once your wallet has finished synchronizing with the litecoin network, as detailed below.</string>
<string>The displayed information may be out of date. Your wallet automatically synchronizes with the Bitcoin network after a connection is established, but this process has not completed yet.</string>
<string>The displayed information may be out of date. Your wallet automatically synchronizes with the Litecoin network after a connection is established, but this process has not completed yet.</string>
</property>
<property name="text">
<string/>
@ -129,7 +129,7 @@
@@ -129,7 +129,7 @@
<string>Unconfirmed transactions to watch-only addresses</string>
<string>The displayed information may be out of date. Your wallet automatically synchronizes with the Bitcoin network after a connection is established, but this process has not completed yet.</string>
<string>The displayed information may be out of date. Your wallet automatically synchronizes with the Litecoin network after a connection is established, but this process has not completed yet.</string>
<string>An optional message to attach to the payment request, which will be displayed when the request is opened. Note: The message will not be sent with the payment over the Bitcoin network.</string>
<string>An optional message to attach to the payment request, which will be displayed when the request is opened. Note: The message will not be sent with the payment over the Litecoin network.</string>
</property>
<property name="text">
<string>&Message:</string>
@ -93,7 +93,7 @@
@@ -93,7 +93,7 @@
<item row="6" column="2">
<widget class="QLineEdit" name="reqMessage">
<property name="toolTip">
<string>An optional message to attach to the payment request, which will be displayed when the request is opened. Note: The message will not be sent with the payment over the Bitcoin network.</string>
<string>An optional message to attach to the payment request, which will be displayed when the request is opened. Note: The message will not be sent with the payment over the Litecoin network.</string>
<string>Paying only the minimum fee is just fine as long as there is less transaction volume than space in the blocks. But be aware that this can end up in a never confirming transaction once there is more demand for bitcoin transactions than the network can process.</string>
<string>Paying only the minimum fee is just fine as long as there is less transaction volume than space in the blocks. But be aware that this can end up in a never confirming transaction once there is more demand for litecoin transactions than the network can process.</string>
</property>
<property name="text">
<string/>
@ -891,7 +891,7 @@
@@ -891,7 +891,7 @@
<bool>true</bool>
</property>
<property name="toolTip">
<string>Paying only the minimum fee is just fine as long as there is less transaction volume than space in the blocks. But be aware that this can end up in a never confirming transaction once there is more demand for bitcoin transactions than the network can process.</string>
<string>Paying only the minimum fee is just fine as long as there is less transaction volume than space in the blocks. But be aware that this can end up in a never confirming transaction once there is more demand for litecoin transactions than the network can process.</string>
<string>The fee will be deducted from the amount being sent. The recipient will receive less bitcoins than you enter in the amount field. If multiple recipients are selected, the fee is split equally.</string>
<string>The fee will be deducted from the amount being sent. The recipient will receive less litecoins than you enter in the amount field. If multiple recipients are selected, the fee is split equally.</string>
</property>
<property name="text">
<string>S&ubtract fee from amount</string>
@ -199,7 +199,7 @@
@@ -199,7 +199,7 @@
<item row="3" column="1">
<widget class="QLabel" name="messageTextLabel">
<property name="toolTip">
<string>A message that was attached to the bitcoin: URI which will be stored with the transaction for your reference. Note: This message will not be sent over the Bitcoin network.</string>
<string>A message that was attached to the litecoin: URI which will be stored with the transaction for your reference. Note: This message will not be sent over the Litecoin network.</string>
<string>You can sign messages/agreements with your addresses to prove you can receive bitcoins sent to them. Be careful not to sign anything vague or random, as phishing attacks may try to trick you into signing your identity over to them. Only sign fully-detailed statements you agree to.</string>
<string>You can sign messages/agreements with your addresses to prove you can receive litecoins sent to them. Be careful not to sign anything vague or random, as phishing attacks may try to trick you into signing your identity over to them. Only sign fully-detailed statements you agree to.</string>
@ -19,13 +19,13 @@ BEGIN
@@ -19,13 +19,13 @@ BEGIN
BEGIN
BLOCK "040904E4" // U.S. English - multilingual (hex)
BEGIN
VALUE "CompanyName", "Bitcoin"
VALUE "FileDescription", PACKAGE_NAME " (GUI node for Bitcoin)"
VALUE "CompanyName", "Litecoin"
VALUE "FileDescription", PACKAGE_NAME " (GUI node for Litecoin)"
VALUE "FileVersion", VER_FILEVERSION_STR
VALUE "InternalName", "bitcoin-qt"
VALUE "InternalName", "litecoin-qt"
VALUE "LegalCopyright", COPYRIGHT_STR
VALUE "LegalTrademarks1", "Distributed under the MIT software license, see the accompanying file COPYING or http://www.opensource.org/licenses/mit-license.php."
"2. \"outputs\" (object, required) a json object with outputs\n"
" {\n"
"\"address\": x.xxx, (numeric or string, required) The key is the bitcoin address, the numeric value (can be string) is the "+CURRENCY_UNIT+" amount\n"
"\"address\": x.xxx, (numeric or string, required) The key is the litecoin address, the numeric value (can be string) is the "+CURRENCY_UNIT+" amount\n"
"\"data\": \"hex\" (string, required) The key is \"data\", the value is hex encoded data\n"
Adrian Gallagher
8 years ago