RanchiMall/FLO-wallet-core
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated doc fodler to FLO; Some READMEs still need wiki/email/talk

Browse Source 
addresses
This commit is contained in:
Ray Engelking 2018-01-05 12:48:36 -05:00
parent c825c2ef81
commit e8a5adfc17
28 changed files with 206 additions and 1531 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.travis.yml
View File

@ -54,9 +54,9 @@ before_script:
- if [ -n "$OSX_SDK" -a -f depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz ]; then tar -C depends/SDKs -xf depends/sdk-sources/MacOSX${OSX_SDK}.sdk.tar.gz; fi
- make $MAKEJOBS -C depends HOST=$HOST $DEP_OPTS
script:
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "litecoin-project/litecoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then while read LINE; do travis_retry gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys $LINE; done < contrib/verify-commits/trusted-keys; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "litecoin-project/litecoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then git fetch --unshallow; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "litecoin-project/litecoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then contrib/verify-commits/verify-commits.sh; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "floblockchain/flo" -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" = "floblockchain/flo" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then git fetch --unshallow; fi
- if [ "$CHECK_DOC" = 1 -a "$TRAVIS_REPO_SLUG" = "floblockchain/flo" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then contrib/verify-commits/verify-commits.sh; fi
- export TRAVIS_COMMIT_LOG=`git log --format=fuller -1`
- if [ -n "$USE_SHELL" ]; then export CONFIG_SHELL="$USE_SHELL"; fi
- OUTDIR=$BASE_OUTDIR/$TRAVIS_PULL_REQUEST/$TRAVIS_JOB_NUMBER-$HOST

2
README.md
View File

@ -1,7 +1,7 @@
Litecoin Core integration/staging tree
=====================================
[![Build Status](https://travis-ci.org/litecoin-project/litecoin.svg?branch=master)](https://travis-ci.org/litecoin-project/litecoin)
[![Build Status](https://travis-ci.org/floblockchain/flo.svg?branch=master)](https://travis-ci.org/floblockchain/flo)
https://litecoin.org

6
depends/README.md
View File

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

22
doc/README.md
View File

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

46
doc/README_windows.txt
View File

@ -1,23 +1,23 @@
Litecoin Core
=============
Intro
-----
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.
Setup
-----
Unpack the files into a directory and run litecoin-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;
depending on the speed of your computer and network connection, the synchronization
process can take anywhere from a few hours to a day or more.
See the litecoin wiki at:
https://litecoin.info/
for more help and information.
FLO Core
=============
Intro
-----
FLO 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.
Setup
-----
Unpack the files into a directory and run flo-qt.exe.
FLO Core is the original FLO client and it builds the backbone of the network.
However, it downloads and stores the entire history of FLO transactions;
depending on the speed of your computer and network connection, the synchronization
process can take anywhere from a few hours to a day or more.
See the litecoin wiki at:
https://litecoin.info/
for more help and information.

4
doc/REST-interface.md
View File

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

2
doc/assets-attribution.md
View File

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

6
doc/benchmarking.md
View File

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

24
doc/build-openbsd.md
View File

@ -2,7 +2,7 @@ OpenBSD build guide
======================
(updated for OpenBSD 6.1)
This guide describes how to build litecoind and command-line utilities on OpenBSD.
This guide describes how to build flod and command-line utilities on OpenBSD.
As OpenBSD is most common as a server OS, we will not bother with the GUI.
@ -18,7 +18,7 @@ pkg_add automake # (select highest version, e.g. 1.15)
pkg_add python # (select highest version, e.g. 3.5)
```
The default C++ compiler that comes with OpenBSD 5.9 is g++ 4.2. This version is old (from 2007), and is not able to compile the current version of Litecoin Core, primarily as it has no C++11 support, but even before there were issues. So here we will be installing a newer compiler.
The default C++ compiler that comes with OpenBSD 5.9 is g++ 4.2. This version is old (from 2007), and is not able to compile the current version of FLO Core, primarily as it has no C++11 support, but even before there were issues. So here we will be installing a newer compiler.
GCC
-------
@ -35,16 +35,16 @@ This compiler will not overwrite the system compiler, it will be installed as `e
Do not use `pkg_add boost`! The boost version installed thus is compiled using the `g++` compiler not `eg++`, which will result in a conflict between `/usr/local/lib/libestdc++.so.XX.0` and `/usr/lib/libstdc++.so.XX.0`, resulting in a test crash:
test_litecoin:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_me ssagesE) size mismatch, relink your program
test_flo:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_me ssagesE) size mismatch, relink your program
...
Segmentation fault (core dumped)
This makes it necessary to build boost, or at least the parts used by Litecoin Core, manually:
This makes it necessary to build boost, or at least the parts used by FLO Core, manually:
```
# Pick some path to install boost to, here we create a directory within the litecoin directory
LITECOIN_ROOT=$(pwd)
BOOST_PREFIX="${LITECOIN_ROOT}/boost"
# Pick some path to install boost to, here we create a directory within the flo directory
FLO_ROOT=$(pwd)
BOOST_PREFIX="${FLO_ROOT}/boost"
mkdir -p $BOOST_PREFIX
# Fetch the source and verify that it is not tampered with
@ -58,7 +58,7 @@ cd boost_1_64_0
# Also here: https://gist.githubusercontent.com/laanwj/bf359281dc319b8ff2e1/raw/92250de8404b97bb99d72ab898f4a8cb35ae1ea3/patch-boost_test_impl_execution_monitor_ipp.patch
patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp
# Build w/ minimum configuration necessary for litecoin
# Build w/ minimum configuration necessary for flo
echo 'using gcc : : eg++ : <cxxflags>"-fvisibility=hidden -fPIC" <linkflags>"" <archiver>"ar" <striper>"strip" <ranlib>"ranlib" <rc>"" : ;' > user-config.jam
config_opts="runtime-link=shared threadapi=pthread threading=multi link=static variant=release --layout=tagged --build-type=complete --user-config=user-config.jam -sNO_BZIP2=1"
./bootstrap.sh --without-icu --with-libraries=chrono,filesystem,program_options,system,thread,test
@ -74,9 +74,9 @@ See "Berkeley DB" in [build_unix.md](build_unix.md) for instructions on how to b
You cannot use the BerkeleyDB library from ports, for the same reason as boost above (g++/libstd++ incompatibility).
```bash
# Pick some path to install BDB to, here we create a directory within the litecoin directory
LITECOIN_ROOT=$(pwd)
BDB_PREFIX="${LITECOIN_ROOT}/db4"
# Pick some path to install BDB to, here we create a directory within the flo directory
FLO_ROOT=$(pwd)
BDB_PREFIX="${FLO_ROOT}/db4"
mkdir -p $BDB_PREFIX
# Fetch the source and verify that it is not tampered with
@ -108,7 +108,7 @@ The change will only affect the current shell and processes spawned by it. To
make the change system-wide, change `datasize-cur` and `datasize-max` in
`/etc/login.conf`, and reboot.
### Building Litecoin Core
### Building FLO Core
**Important**: use `gmake`, not `make`. The non-GNU `make` will exit with a horrible error.

30
doc/build-osx.md
View File

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

42
doc/build-unix.md
View File

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

6
doc/build-windows.md
View File

@ -1,7 +1,7 @@
WINDOWS BUILD NOTES
====================
Below are some notes on how to build Litecoin Core for Windows.
Below are some notes on how to build FLO Core for Windows.
Most developers use cross-compilation from Ubuntu to build executables for
Windows. This is also used to build the release binaries.
@ -102,6 +102,6 @@ Installation
After building using the Windows subsystem it can be useful to copy the compiled
executables to a directory on the windows drive in the same directory structure
as they appear in the release `.zip` archive. This can be done in the following
way. This will install to `c:\workspace\litecoin`, for example:
way. This will install to `c:\workspace\flo`, for example:
make install DESTDIR=/mnt/c/workspace/litecoin
make install DESTDIR=/mnt/c/workspace/flo

24
doc/developer-notes.md
View File

@ -151,7 +151,7 @@ to see it.
**testnet and regtest modes**
Run with the -testnet option to run with "play litecoins" on the test network, if you
Run with the -testnet option to run with "play flos" on the test network, if you
are testing multi-machine code that needs to operate across the internet.
If you are testing something that can run on one machine, run with the -regtest option.
@ -160,7 +160,7 @@ that run in -regtest mode.
**DEBUG_LOCKORDER**
Litecoin Core is a multithreaded application, and deadlocks or other multithreading bugs
FLO Core is a multithreaded application, and deadlocks or other multithreading bugs
can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure
CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks
are held, and adds warnings to the debug.log file if inconsistencies are detected.
@ -195,7 +195,7 @@ Threads
- ThreadMapPort : Universal plug-and-play startup/shutdown
- ThreadSocketHandler : Sends/Receives data from peers on port 9333.
- ThreadSocketHandler : Sends/Receives data from peers on port 7313.
- ThreadOpenAddedConnections : Opens network connections to added nodes.
@ -207,9 +207,9 @@ Threads
- ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms.
- ThreadRPCServer : Remote procedure call handler, listens on port 9332 for connections and services them.
- ThreadRPCServer : Remote procedure call handler, listens on port 7312 for connections and services them.
- BitcoinMiner : Generates litecoins (if wallet is enabled).
- BitcoinMiner : Generates flos (if wallet is enabled).
- Shutdown : Does an orderly shutdown of everything.
@ -219,7 +219,7 @@ Ignoring IDE/editor files
In closed-source environments in which everyone uses the same IDE it is common
to add temporary files it produces to the project-wide `.gitignore` file.
However, in open source software such as Litecoin Core, where everyone uses
However, in open source software such as FLO Core, where everyone uses
their own editors/IDE/tools, it is less common. Only you know what files your
editor produces and this may change from version to version. The canonical way
to do this is thus to create your local gitignore. Add this to `~/.gitconfig`:
@ -249,9 +249,9 @@ Development guidelines
============================
A few non-style-related recommendations for developers, as well as points to
pay attention to for reviewers of Litecoin Core code.
pay attention to for reviewers of FLO Core code.
General Litecoin Core
General FLO Core
----------------------
- New features should be exposed on RPC first, then can be made available in the GUI
@ -361,7 +361,7 @@ Strings and formatting
- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
- *Rationale*: Litecoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion
- *Rationale*: FLO Core uses tinyformat, which is type safe. Leave them out to avoid confusion
Variable names
--------------
@ -467,12 +467,12 @@ Subtrees
Several parts of the repository are subtrees of software maintained elsewhere.
Some of these are maintained by active developers of Litecoin Core, in which case changes should probably go
Some of these are maintained by active developers of FLO Core, in which case changes should probably go
directly upstream without being PRed directly against the project. They will be merged back in the next
subtree merge.
Others are external projects without a tight relationship with our project. Changes to these should also
be sent upstream but bugfixes may also be prudent to PR against Litecoin Core so that they can be integrated
be sent upstream but bugfixes may also be prudent to PR against FLO Core so that they can be integrated
quickly. Cosmetic changes should be purely taken upstream.
There is a tool in contrib/devtools/git-subtree-check.sh to check a subtree directory for consistency with
@ -535,7 +535,7 @@ Git and GitHub tips
[remote "upstream-pull"]
fetch = +refs/pull/*:refs/remotes/upstream-pull/*
url = git@github.com:litecoin-project/litecoin.git
url = git@github.com:floblockchain/flo.git
This will add an `upstream-pull` remote to your git repository, which can be fetched using `git fetch --all`
or `git fetch upstream-pull`. Afterwards, you can use `upstream-pull/NUMBER/head` in arguments to `git show`,

12
doc/dnsseed-policy.md
View File

@ -1,12 +1,12 @@
Expectations for DNS Seed operators
====================================
Litecoin Core attempts to minimize the level of trust in DNS seeds,
FLO 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 FLO community.
Other implementations of Litecoin software may also use the same
Other implementations of FLO software may also use the same
seeds and may be more exposed. In light of this exposure, this
document establishes some basic expectations for operating dnsseeds.
@ -16,7 +16,7 @@ and not sell or transfer control of the DNS seed. Any hosting services
contracted by the operator are equally expected to uphold these expectations.
1. The DNS seed results must consist exclusively of fairly selected and
functioning Litecoin nodes from the public network to the best of the
functioning FLO nodes from the public network to the best of the
operator's understanding and capability.
2. For the avoidance of doubt, the results may be randomized but must not
@ -26,7 +26,7 @@ urgent technical necessity and disclosed.
3. The results may not be served with a DNS TTL of less than one minute.
4. Any logging of DNS queries should be only that which is necessary
for the operation of the service or urgent health of the Litecoin
for the operation of the service or urgent health of the FLO
network and must not be retained longer than necessary nor disclosed
to any third party.
@ -42,7 +42,7 @@ 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 FLO
Core development team as well as posting on
[litecoin-dev](https://groups.google.com/forum/#!forum/litecoin-dev).

6
doc/files.md
View File

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

10
doc/fuzzing.md
View File

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

48
doc/gitian-building.md
View File

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

6
doc/man/Makefile.am
View File

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

94
doc/man/litecoin-cli.1
View File

@ -1,94 +0,0 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIN-CLI "1" "September 2017" "litecoin-cli v0.15.0.1" "User Commands"
.SH NAME
litecoin-cli \- manual page for litecoin-cli v0.15.0.1
.SH DESCRIPTION
Litecoin Core RPC client version v0.15.0.1\-dirty
.SS "Usage:"
.TP
litecoin\-cli [options] <command> [params]
Send command to Litecoin Core
.IP
litecoin\-cli [options] \fB\-named\fR <command> [name=value] ... Send command to Litecoin Core (with named arguments)
litecoin\-cli [options] help List commands
litecoin\-cli [options] help <command> Get help for a command
.SH OPTIONS
.HP
\-?
.IP
This help message
.HP
\fB\-conf=\fR<file>
.IP
Specify configuration file (default: litecoin.conf)
.HP
\fB\-datadir=\fR<dir>
.IP
Specify data directory
.PP
Chain selection options:
.HP
\fB\-testnet\fR
.IP
Use the test chain
.HP
\fB\-regtest\fR
.IP
Enter regression test mode, which uses a special chain in which blocks
can be solved instantly. This is intended for regression testing
tools and app development.
.HP
\fB\-named\fR
.IP
Pass named instead of positional arguments (default: false)
.HP
\fB\-rpcconnect=\fR<ip>
.IP
Send commands to node running on <ip> (default: 127.0.0.1)
.HP
\fB\-rpcport=\fR<port>
.IP
Connect to JSON\-RPC on <port> (default: 9332 or testnet: 19332)
.HP
\fB\-rpcwait\fR
.IP
Wait for RPC server to start
.HP
\fB\-rpcuser=\fR<user>
.IP
Username for JSON\-RPC connections
.HP
\fB\-rpcpassword=\fR<pw>
.IP
Password for JSON\-RPC connections
.HP
\fB\-rpcclienttimeout=\fR<n>
.IP
Timeout in seconds during HTTP requests, or 0 for no timeout. (default:
900)
.HP
\fB\-stdin\fR
.IP
Read extra arguments from standard input, one per line until EOF/Ctrl\-D
(recommended for sensitive information such as passphrases)
.HP
\fB\-rpcwallet=\fR<walletname>
.IP
Send RPC for non\-default wallet on RPC server (argument is wallet
filename in litecoind directory, required if litecoind/\-Qt runs
with multiple wallets)
.SH COPYRIGHT
Copyright (C) 2009-2017 The Bitcoin Core developers
Copyright (C) 2011-2017 The Litecoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
The source code is available from <https://github.com/floblockchain/flo>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>
This product includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit <https://www.openssl.org> and cryptographic software written by
Eric Young and UPnP software written by Thomas Bernard.

562
doc/man/litecoin-qt.1
View File

@ -1,562 +0,0 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIN-QT "1" "September 2017" "litecoin-qt v0.15.0.1" "User Commands"
.SH NAME
litecoin-qt \- manual page for litecoin-qt v0.15.0.1
.SH DESCRIPTION
Litecoin Core version v0.15.0.1\-dirty (64\-bit)
Usage:
.IP
litecoin\-qt [command\-line options]
.SH OPTIONS
.HP
\-?
.IP
Print this help message and exit
.HP
\fB\-version\fR
.IP
Print version and exit
.HP
\fB\-alertnotify=\fR<cmd>
.IP
Execute command when a relevant alert is received or we see a really
long fork (%s in cmd is replaced by message)
.HP
\fB\-blocknotify=\fR<cmd>
.IP
Execute command when the best block changes (%s in cmd is replaced by
block hash)
.HP
\fB\-assumevalid=\fR<hex>
.IP
If this block is in the chain assume that it and its ancestors are valid
and potentially skip their script verification (0 to verify all,
default:
29c8c00e1a5f446a6364a29633d3f1ee16428d87c8d3851a1c570be8170b04c2,
testnet:
ad8ff6c2f5580d2b50bd881e11312425ea84fa99f322bf132beb722f97971bba)
.HP
\fB\-conf=\fR<file>
.IP
Specify configuration file (default: litecoin.conf)
.HP
\fB\-datadir=\fR<dir>
.IP
Specify data directory
.HP
\fB\-dbcache=\fR<n>
.IP
Set database cache size in megabytes (4 to 16384, default: 450)
.HP
\fB\-loadblock=\fR<file>
.IP
Imports blocks from external blk000??.dat file on startup
.HP
\fB\-maxorphantx=\fR<n>
.IP
Keep at most <n> unconnectable transactions in memory (default: 100)
.HP
\fB\-maxmempool=\fR<n>
.IP
Keep the transaction memory pool below <n> megabytes (default: 5)
.HP
\fB\-mempoolexpiry=\fR<n>
.IP
Do not keep transactions in the mempool longer than <n> hours (default:
336)
.HP
\fB\-persistmempool\fR
.IP
Whether to save the mempool on shutdown and load on restart (default: 1)
.HP
\fB\-blockreconstructionextratxn=\fR<n>
.IP
Extra transactions to keep in memory for compact block reconstructions
(default: 100)
.HP
\fB\-par=\fR<n>
.IP
Set the number of script verification threads (\fB\-6\fR to 16, 0 = auto, <0 =
leave that many cores free, default: 0)
.HP
\fB\-pid=\fR<file>
.IP
Specify pid file (default: litecoind.pid)
.HP
\fB\-prune=\fR<n>
.IP
Reduce storage requirements by enabling pruning (deleting) of old
blocks. This allows the pruneblockchain RPC to be called to
delete specific blocks, and enables automatic pruning of old
blocks if a target size in MiB is provided. This mode is
incompatible with \fB\-txindex\fR and \fB\-rescan\fR. Warning: Reverting this
setting requires re\-downloading the entire blockchain. (default:
0 = disable pruning blocks, 1 = allow manual pruning via RPC,
>550 = automatically prune block files to stay under the
specified target size in MiB)
.HP
\fB\-reindex\-chainstate\fR
.IP
Rebuild chain state from the currently indexed blocks
.HP
\fB\-reindex\fR
.IP
Rebuild chain state and block index from the blk*.dat files on disk
.HP
\fB\-sysperms\fR
.IP
Create new files with system default permissions, instead of umask 077
(only effective with disabled wallet functionality)
.HP
\fB\-txindex\fR
.IP
Maintain a full transaction index, used by the getrawtransaction rpc
call (default: 0)
.PP
Connection options:
.HP
\fB\-addnode=\fR<ip>
.IP
Add a node to connect to and attempt to keep the connection open
.HP
\fB\-banscore=\fR<n>
.IP
Threshold for disconnecting misbehaving peers (default: 100)
.HP
\fB\-bantime=\fR<n>
.IP
Number of seconds to keep misbehaving peers from reconnecting (default:
86400)
.HP
\fB\-bind=\fR<addr>
.IP
Bind to given address and always listen on it. Use [host]:port notation
for IPv6
.HP
\fB\-connect=\fR<ip>
.IP
Connect only to the specified node(s); \fB\-connect\fR=\fI\,0\/\fR disables automatic
connections
.HP
\fB\-discover\fR
.IP
Discover own IP addresses (default: 1 when listening and no \fB\-externalip\fR
or \fB\-proxy\fR)
.HP
\fB\-dns\fR
.IP
Allow DNS lookups for \fB\-addnode\fR, \fB\-seednode\fR and \fB\-connect\fR (default: 1)
.HP
\fB\-dnsseed\fR
.IP
Query for peer addresses via DNS lookup, if low on addresses (default: 1
unless \fB\-connect\fR used)
.HP
\fB\-externalip=\fR<ip>
.IP
Specify your own public address
.HP
\fB\-forcednsseed\fR
.IP
Always query for peer addresses via DNS lookup (default: 0)
.HP
\fB\-listen\fR
.IP
Accept connections from outside (default: 1 if no \fB\-proxy\fR or \fB\-connect\fR)
.HP
\fB\-listenonion\fR
.IP
Automatically create Tor hidden service (default: 1)
.HP
\fB\-maxconnections=\fR<n>
.IP
Maintain at most <n> connections to peers (default: 125)
.HP
\fB\-maxreceivebuffer=\fR<n>
.IP
Maximum per\-connection receive buffer, <n>*1000 bytes (default: 5000)
.HP
\fB\-maxsendbuffer=\fR<n>
.IP
Maximum per\-connection send buffer, <n>*1000 bytes (default: 1000)
.HP
\fB\-maxtimeadjustment\fR
.IP
Maximum allowed median peer time offset adjustment. Local perspective of
time may be influenced by peers forward or backward by this
amount. (default: 4200 seconds)
.HP
\fB\-onion=\fR<ip:port>
.IP
Use separate SOCKS5 proxy to reach peers via Tor hidden services
(default: \fB\-proxy\fR)
.HP
\fB\-onlynet=\fR<net>
.IP
Only connect to nodes in network <net> (ipv4, ipv6 or onion)
.HP
\fB\-permitbaremultisig\fR
.IP
Relay non\-P2SH multisig (default: 1)
.HP
\fB\-peerbloomfilters\fR
.IP
Support filtering of blocks and transaction with bloom filters (default:
1)
.HP
\fB\-port=\fR<port>
.IP
Listen for connections on <port> (default: 8333 or testnet: 18333)
.HP
\fB\-proxy=\fR<ip:port>
.IP
Connect through SOCKS5 proxy
.HP
\fB\-proxyrandomize\fR
.IP
Randomize credentials for every proxy connection. This enables Tor
stream isolation (default: 1)
.HP
\fB\-seednode=\fR<ip>
.IP
Connect to a node to retrieve peer addresses, and disconnect
.HP
\fB\-timeout=\fR<n>
.IP
Specify connection timeout in milliseconds (minimum: 1, default: 5000)
.HP
\fB\-torcontrol=\fR<ip>:<port>
.IP
Tor control port to use if onion listening enabled (default:
127.0.0.1:9051)
.HP
\fB\-torpassword=\fR<pass>
.IP
Tor control port password (default: empty)
.HP
\fB\-upnp\fR
.IP
Use UPnP to map the listening port (default: 0)
.HP
\fB\-whitebind=\fR<addr>
.IP
Bind to given address and whitelist peers connecting to it. Use
[host]:port notation for IPv6
.HP
\fB\-whitelist=\fR<IP address or network>
.IP
Whitelist peers connecting from the given IP address (e.g. 1.2.3.4) or
CIDR notated network (e.g. 1.2.3.0/24). Can be specified multiple
times. Whitelisted peers cannot be DoS banned and their
transactions are always relayed, even if they are already in the
mempool, useful e.g. for a gateway
.HP
\fB\-maxuploadtarget=\fR<n>
.IP
Tries to keep outbound traffic under the given target (in MiB per 24h),
0 = no limit (default: 0)
.PP
Wallet options:
.HP
\fB\-disablewallet\fR
.IP
Do not load the wallet and disable wallet RPC calls
.HP
\fB\-keypool=\fR<n>
.IP
Set key pool size to <n> (default: 1000)
.HP
\fB\-fallbackfee=\fR<amt>
.IP
A fee rate (in LTC/kB) that will be used when fee estimation has
insufficient data (default: 0.002)
.HP
\fB\-discardfee=\fR<amt>
.IP
The fee rate (in LTC/kB) that indicates your tolerance for discarding
change by adding it to the fee (default: 0.0001). Note: An output
is discarded if it is dust at this rate, but we will always
discard up to the dust relay fee and a discard fee above that is
limited by the fee estimate for the longest target
.HP
\fB\-mintxfee=\fR<amt>
.IP
Fees (in LTC/kB) smaller than this are considered zero fee for
transaction creation (default: 0.001)
.HP
\fB\-paytxfee=\fR<amt>
.IP
Fee (in LTC/kB) to add to transactions you send (default: 0.00)
.HP
\fB\-rescan\fR
.IP
Rescan the block chain for missing wallet transactions on startup
.HP
\fB\-salvagewallet\fR
.IP
Attempt to recover private keys from a corrupt wallet on startup
.HP
\fB\-spendzeroconfchange\fR
.IP
Spend unconfirmed change when sending transactions (default: 1)
.HP
\fB\-txconfirmtarget=\fR<n>
.IP
If paytxfee is not set, include enough fee so transactions begin
confirmation on average within n blocks (default: 6)
.HP
\fB\-usehd\fR
.IP
Use hierarchical deterministic key generation (HD) after BIP32. Only has
effect during wallet creation/first start (default: 1)
.HP
\fB\-walletrbf\fR
.IP
Send transactions with full\-RBF opt\-in enabled (default: 0)
.HP
\fB\-upgradewallet\fR
.IP
Upgrade wallet to latest format on startup
.HP
\fB\-wallet=\fR<file>
.IP
Specify wallet file (within data directory) (default: wallet.dat)
.HP
\fB\-walletbroadcast\fR
.IP
Make the wallet broadcast transactions (default: 1)
.HP
\fB\-walletnotify=\fR<cmd>
.IP
Execute command when a wallet transaction changes (%s in cmd is replaced
by TxID)
.HP
\fB\-zapwallettxes=\fR<mode>
.IP
Delete all wallet transactions and only recover those parts of the
blockchain through \fB\-rescan\fR on startup (1 = keep tx meta data e.g.
account owner and payment request information, 2 = drop tx meta
data)
.PP
ZeroMQ notification options:
.HP
\fB\-zmqpubhashblock=\fR<address>
.IP
Enable publish hash block in <address>
.HP
\fB\-zmqpubhashtx=\fR<address>
.IP
Enable publish hash transaction in <address>
.HP
\fB\-zmqpubrawblock=\fR<address>
.IP
Enable publish raw block in <address>
.HP
\fB\-zmqpubrawtx=\fR<address>
.IP
Enable publish raw transaction in <address>
.PP
Debugging/Testing options:
.HP
\fB\-uacomment=\fR<cmt>
.IP
Append comment to the user agent string
.HP
\fB\-debug=\fR<category>
.IP
Output debugging information (default: 0, supplying <category> is
optional). If <category> is not supplied or if <category> = 1,
output all debugging information. <category> can be: net, tor,
mempool, http, bench, zmq, db, rpc, estimatefee, addrman,
selectcoins, reindex, cmpctblock, rand, prune, proxy, mempoolrej,
libevent, coindb, qt, leveldb.
.HP
\fB\-debugexclude=\fR<category>
.IP
Exclude debugging information for a category. Can be used in conjunction
with \fB\-debug\fR=\fI\,1\/\fR to output debug logs for all categories except one
or more specified categories.
.HP
\fB\-help\-debug\fR
.IP
Show all debugging options (usage: \fB\-\-help\fR \fB\-help\-debug\fR)
.HP
\fB\-logips\fR
.IP
Include IP addresses in debug output (default: 0)
.HP
\fB\-logtimestamps\fR
.IP
Prepend debug output with timestamp (default: 1)
.HP
\fB\-maxtxfee=\fR<amt>
.IP
Maximum total fees (in LTC) to use in a single wallet transaction or raw
transaction; setting this too low may abort large transactions
(default: 0.10)
.HP
\fB\-printtoconsole\fR
.IP
Send trace/debug info to console instead of debug.log file
.HP
\fB\-shrinkdebugfile\fR
.IP
Shrink debug.log file on client startup (default: 1 when no \fB\-debug\fR)
.PP
Chain selection options:
.HP
\fB\-testnet\fR
.IP
Use the test chain
.PP
Node relay options:
.HP
\fB\-bytespersigop\fR
.IP
Equivalent bytes per sigop in transactions for relay and mining
(default: 20)
.HP
\fB\-datacarrier\fR
.IP
Relay and mine data carrier transactions (default: 1)
.HP
\fB\-datacarriersize\fR
.IP
Maximum size of data in data carrier transactions we relay and mine
(default: 83)
.HP
\fB\-mempoolreplacement\fR
.IP
Enable transaction replacement in the memory pool (default: 1)
.HP
\fB\-minrelaytxfee=\fR<amt>
.IP
Fees (in LTC/kB) smaller than this are considered zero fee for relaying,
mining and transaction creation (default: 0.001)
.HP
\fB\-whitelistrelay\fR
.IP
Accept relayed transactions received from whitelisted peers even when
not relaying transactions (default: 1)
.HP
\fB\-whitelistforcerelay\fR
.IP
Force relay of transactions from whitelisted peers even if they violate
local relay policy (default: 1)
.PP
Block creation options:
.HP
\fB\-blockmaxweight=\fR<n>
.IP
Set maximum BIP141 block weight (default: 3000000)
.HP
\fB\-blockmaxsize=\fR<n>
.IP
Set maximum block size in bytes (default: 750000)
.HP
\fB\-blockmintxfee=\fR<amt>
.IP
Set lowest fee rate (in LTC/kB) for transactions to be included in block
creation. (default: 0.00001)
.PP
RPC server options:
.HP
\fB\-server\fR
.IP
Accept command line and JSON\-RPC commands
.HP
\fB\-rest\fR
.IP
Accept public REST requests (default: 0)
.HP
\fB\-rpcbind=\fR<addr>[:port]
.IP
Bind to given address to listen for JSON\-RPC connections. This option is
ignored unless \fB\-rpcallowip\fR is also passed. Port is optional and
overrides \fB\-rpcport\fR. Use [host]:port notation for IPv6. This
option can be specified multiple times (default: 127.0.0.1 and
::1 i.e., localhost, or if \fB\-rpcallowip\fR has been specified,
0.0.0.0 and :: i.e., all addresses)
.HP
\fB\-rpccookiefile=\fR<loc>
.IP
Location of the auth cookie (default: data dir)
.HP
\fB\-rpcuser=\fR<user>
.IP
Username for JSON\-RPC connections
.HP
\fB\-rpcpassword=\fR<pw>
.IP
Password for JSON\-RPC connections
.HP
\fB\-rpcauth=\fR<userpw>
.IP
Username and hashed password for JSON\-RPC connections. The field
<userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. A
canonical python script is included in share/rpcuser. The client
then connects normally using the
rpcuser=<USERNAME>/rpcpassword=<PASSWORD> pair of arguments. This
option can be specified multiple times
.HP
\fB\-rpcport=\fR<port>
.IP
Listen for JSON\-RPC connections on <port> (default: 9332 or testnet:
19332)
.HP
\fB\-rpcallowip=\fR<ip>
.IP
Allow JSON\-RPC connections from specified source. Valid for <ip> are a
single IP (e.g. 1.2.3.4), a network/netmask (e.g.
1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This
option can be specified multiple times
.HP
\fB\-rpcserialversion\fR
.IP
Sets the serialization of raw transaction or block hex returned in
non\-verbose mode, non\-segwit(0) or segwit(1) (default: 1)
.HP
\fB\-rpcthreads=\fR<n>
.IP
Set the number of threads to service RPC calls (default: 4)
.PP
UI Options:
.HP
\fB\-choosedatadir\fR
.IP
Choose data directory on startup (default: 0)
.HP
\fB\-lang=\fR<lang>
.IP
Set language, for example "de_DE" (default: system locale)
.HP
\fB\-min\fR
.IP
Start minimized
.HP
\fB\-rootcertificates=\fR<file>
.IP
Set SSL root certificates for payment request (default: \fB\-system\-\fR)
.HP
\fB\-splash\fR
.IP
Show splash screen on startup (default: 1)
.HP
\fB\-resetguisettings\fR
.IP
Reset all settings changed in the GUI
.SH COPYRIGHT
Copyright (C) 2009-2017 The Bitcoin Core developers
Copyright (C) 2011-2017 The Litecoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
The source code is available from <https://github.com/floblockchain/flo>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>
This product includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit <https://www.openssl.org> and cryptographic software written by
Eric Young and UPnP software written by Thomas Bernard.

128
doc/man/litecoin-tx.1
View File

@ -1,128 +0,0 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIN-TX "1" "September 2017" "litecoin-tx v0.15.0.1" "User Commands"
.SH NAME
litecoin-tx \- manual page for litecoin-tx v0.15.0.1
.SH DESCRIPTION
Litecoin Core litecoin\-tx utility version v0.15.0.1\-dirty
.SS "Usage:"
.TP
litecoin\-tx [options] <hex\-tx> [commands]
Update hex\-encoded litecoin transaction
.TP
litecoin\-tx [options] \fB\-create\fR [commands]
Create hex\-encoded litecoin transaction
.SH OPTIONS
.HP
\-?
.IP
This help message
.HP
\fB\-create\fR
.IP
Create new, empty TX.
.HP
\fB\-json\fR
.IP
Select JSON output
.HP
\fB\-txid\fR
.IP
Output only the hex\-encoded transaction id of the resultant transaction.
.PP
Chain selection options:
.HP
\fB\-testnet\fR
.IP
Use the test chain
.HP
\fB\-regtest\fR
.IP
Enter regression test mode, which uses a special chain in which blocks
can be solved instantly. This is intended for regression testing
tools and app development.
.PP
Commands:
.IP
delin=N
.IP
Delete input N from TX
.IP
delout=N
.IP
Delete output N from TX
.IP
in=TXID:VOUT(:SEQUENCE_NUMBER)
.IP
Add input to TX
.IP
locktime=N
.IP
Set TX lock time to N
.IP
nversion=N
.IP
Set TX version to N
.IP
replaceable(=N)
.IP
Set RBF opt\-in sequence number for input N (if not provided, opt\-in all
available inputs)
.IP
outaddr=VALUE:ADDRESS
.IP
Add address\-based output to TX
.IP
outpubkey=VALUE:PUBKEY[:FLAGS]
.IP
Add pay\-to\-pubkey output to TX. Optionally add the "W" flag to produce a
pay\-to\-witness\-pubkey\-hash output. Optionally add the "S" flag to
wrap the output in a pay\-to\-script\-hash.
.IP
outdata=[VALUE:]DATA
.IP
Add data\-based output to TX
.IP
outscript=VALUE:SCRIPT[:FLAGS]
.IP
Add raw script output to TX. Optionally add the "W" flag to produce a
pay\-to\-witness\-script\-hash output. Optionally add the "S" flag to
wrap the output in a pay\-to\-script\-hash.
.IP
outmultisig=VALUE:REQUIRED:PUBKEYS:PUBKEY1:PUBKEY2:....[:FLAGS]
.IP
Add Pay To n\-of\-m Multi\-sig output to TX. n = REQUIRED, m = PUBKEYS.
Optionally add the "W" flag to produce a
pay\-to\-witness\-script\-hash output. Optionally add the "S" flag to
wrap the output in a pay\-to\-script\-hash.
.IP
sign=SIGHASH\-FLAGS
.IP
Add zero or more signatures to transaction. This command requires JSON
registers:prevtxs=JSON object, privatekeys=JSON object. See
signrawtransaction docs for format of sighash flags, JSON
objects.
.PP
Register Commands:
.IP
load=NAME:FILENAME
.IP
Load JSON file FILENAME into register NAME
.IP
set=NAME:JSON\-STRING
.IP
Set register NAME to given JSON\-STRING
.SH COPYRIGHT
Copyright (C) 2009-2017 The Bitcoin Core developers
Copyright (C) 2011-2017 The Litecoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
The source code is available from <https://github.com/floblockchain/flo>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>
This product includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit <https://www.openssl.org> and cryptographic software written by
Eric Young and UPnP software written by Thomas Bernard.

541
doc/man/litecoind.1
View File

@ -1,541 +0,0 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.3.
.TH LITECOIND "1" "September 2017" "litecoind v0.15.0.1" "User Commands"
.SH NAME
litecoind \- manual page for litecoind v0.15.0.1
.SH DESCRIPTION
Litecoin Core Daemon version v0.15.0.1\-dirty
.SS "Usage:"
.TP
litecoind [options]
Start Litecoin Core Daemon
.SH OPTIONS
.HP
\-?
.IP
Print this help message and exit
.HP
\fB\-version\fR
.IP
Print version and exit
.HP
\fB\-alertnotify=\fR<cmd>
.IP
Execute command when a relevant alert is received or we see a really
long fork (%s in cmd is replaced by message)
.HP
\fB\-blocknotify=\fR<cmd>
.IP
Execute command when the best block changes (%s in cmd is replaced by
block hash)
.HP
\fB\-assumevalid=\fR<hex>
.IP
If this block is in the chain assume that it and its ancestors are valid
and potentially skip their script verification (0 to verify all,
default:
29c8c00e1a5f446a6364a29633d3f1ee16428d87c8d3851a1c570be8170b04c2,
testnet:
ad8ff6c2f5580d2b50bd881e11312425ea84fa99f322bf132beb722f97971bba)
.HP
\fB\-conf=\fR<file>
.IP
Specify configuration file (default: litecoin.conf)
.HP
\fB\-daemon\fR
.IP
Run in the background as a daemon and accept commands
.HP
\fB\-datadir=\fR<dir>
.IP
Specify data directory
.HP
\fB\-dbcache=\fR<n>
.IP
Set database cache size in megabytes (4 to 16384, default: 450)
.HP
\fB\-loadblock=\fR<file>
.IP
Imports blocks from external blk000??.dat file on startup
.HP
\fB\-maxorphantx=\fR<n>
.IP
Keep at most <n> unconnectable transactions in memory (default: 100)
.HP
\fB\-maxmempool=\fR<n>
.IP
Keep the transaction memory pool below <n> megabytes (default: 5)
.HP
\fB\-mempoolexpiry=\fR<n>
.IP
Do not keep transactions in the mempool longer than <n> hours (default:
336)
.HP
\fB\-persistmempool\fR
.IP
Whether to save the mempool on shutdown and load on restart (default: 1)
.HP
\fB\-blockreconstructionextratxn=\fR<n>
.IP
Extra transactions to keep in memory for compact block reconstructions
(default: 100)
.HP
\fB\-par=\fR<n>
.IP
Set the number of script verification threads (\fB\-6\fR to 16, 0 = auto, <0 =
leave that many cores free, default: 0)
.HP
\fB\-pid=\fR<file>
.IP
Specify pid file (default: litecoind.pid)
.HP
\fB\-prune=\fR<n>
.IP
Reduce storage requirements by enabling pruning (deleting) of old
blocks. This allows the pruneblockchain RPC to be called to
delete specific blocks, and enables automatic pruning of old
blocks if a target size in MiB is provided. This mode is
incompatible with \fB\-txindex\fR and \fB\-rescan\fR. Warning: Reverting this
setting requires re\-downloading the entire blockchain. (default:
0 = disable pruning blocks, 1 = allow manual pruning via RPC,
>550 = automatically prune block files to stay under the
specified target size in MiB)
.HP
\fB\-reindex\-chainstate\fR
.IP
Rebuild chain state from the currently indexed blocks
.HP
\fB\-reindex\fR
.IP
Rebuild chain state and block index from the blk*.dat files on disk
.HP
\fB\-sysperms\fR
.IP
Create new files with system default permissions, instead of umask 077
(only effective with disabled wallet functionality)
.HP
\fB\-txindex\fR
.IP
Maintain a full transaction index, used by the getrawtransaction rpc
call (default: 0)
.PP
Connection options:
.HP
\fB\-addnode=\fR<ip>
.IP
Add a node to connect to and attempt to keep the connection open
.HP
\fB\-banscore=\fR<n>
.IP
Threshold for disconnecting misbehaving peers (default: 100)
.HP
\fB\-bantime=\fR<n>
.IP
Number of seconds to keep misbehaving peers from reconnecting (default:
86400)
.HP
\fB\-bind=\fR<addr>
.IP
Bind to given address and always listen on it. Use [host]:port notation
for IPv6
.HP
\fB\-connect=\fR<ip>
.IP
Connect only to the specified node(s); \fB\-connect\fR=\fI\,0\/\fR disables automatic
connections
.HP
\fB\-discover\fR
.IP
Discover own IP addresses (default: 1 when listening and no \fB\-externalip\fR
or \fB\-proxy\fR)
.HP
\fB\-dns\fR
.IP
Allow DNS lookups for \fB\-addnode\fR, \fB\-seednode\fR and \fB\-connect\fR (default: 1)
.HP
\fB\-dnsseed\fR
.IP
Query for peer addresses via DNS lookup, if low on addresses (default: 1
unless \fB\-connect\fR used)
.HP
\fB\-externalip=\fR<ip>
.IP
Specify your own public address
.HP
\fB\-forcednsseed\fR
.IP
Always query for peer addresses via DNS lookup (default: 0)
.HP
\fB\-listen\fR
.IP
Accept connections from outside (default: 1 if no \fB\-proxy\fR or \fB\-connect\fR)
.HP
\fB\-listenonion\fR
.IP
Automatically create Tor hidden service (default: 1)
.HP
\fB\-maxconnections=\fR<n>
.IP
Maintain at most <n> connections to peers (default: 125)
.HP
\fB\-maxreceivebuffer=\fR<n>
.IP
Maximum per\-connection receive buffer, <n>*1000 bytes (default: 5000)
.HP
\fB\-maxsendbuffer=\fR<n>
.IP
Maximum per\-connection send buffer, <n>*1000 bytes (default: 1000)
.HP
\fB\-maxtimeadjustment\fR
.IP
Maximum allowed median peer time offset adjustment. Local perspective of
time may be influenced by peers forward or backward by this
amount. (default: 4200 seconds)
.HP
\fB\-onion=\fR<ip:port>
.IP
Use separate SOCKS5 proxy to reach peers via Tor hidden services
(default: \fB\-proxy\fR)
.HP
\fB\-onlynet=\fR<net>
.IP
Only connect to nodes in network <net> (ipv4, ipv6 or onion)
.HP
\fB\-permitbaremultisig\fR
.IP
Relay non\-P2SH multisig (default: 1)
.HP
\fB\-peerbloomfilters\fR
.IP
Support filtering of blocks and transaction with bloom filters (default:
1)
.HP
\fB\-port=\fR<port>
.IP
Listen for connections on <port> (default: 8333 or testnet: 18333)
.HP
\fB\-proxy=\fR<ip:port>
.IP
Connect through SOCKS5 proxy
.HP
\fB\-proxyrandomize\fR
.IP
Randomize credentials for every proxy connection. This enables Tor
stream isolation (default: 1)
.HP
\fB\-seednode=\fR<ip>
.IP
Connect to a node to retrieve peer addresses, and disconnect
.HP
\fB\-timeout=\fR<n>
.IP
Specify connection timeout in milliseconds (minimum: 1, default: 5000)
.HP
\fB\-torcontrol=\fR<ip>:<port>
.IP
Tor control port to use if onion listening enabled (default:
127.0.0.1:9051)
.HP
\fB\-torpassword=\fR<pass>
.IP
Tor control port password (default: empty)
.HP
\fB\-upnp\fR
.IP
Use UPnP to map the listening port (default: 0)
.HP
\fB\-whitebind=\fR<addr>
.IP
Bind to given address and whitelist peers connecting to it. Use
[host]:port notation for IPv6
.HP
\fB\-whitelist=\fR<IP address or network>
.IP
Whitelist peers connecting from the given IP address (e.g. 1.2.3.4) or
CIDR notated network (e.g. 1.2.3.0/24). Can be specified multiple
times. Whitelisted peers cannot be DoS banned and their
transactions are always relayed, even if they are already in the
mempool, useful e.g. for a gateway
.HP
\fB\-maxuploadtarget=\fR<n>
.IP
Tries to keep outbound traffic under the given target (in MiB per 24h),
0 = no limit (default: 0)
.PP
Wallet options:
.HP
\fB\-disablewallet\fR
.IP
Do not load the wallet and disable wallet RPC calls
.HP
\fB\-keypool=\fR<n>
.IP
Set key pool size to <n> (default: 1000)
.HP
\fB\-fallbackfee=\fR<amt>
.IP
A fee rate (in LTC/kB) that will be used when fee estimation has
insufficient data (default: 0.002)
.HP
\fB\-discardfee=\fR<amt>
.IP
The fee rate (in BTC/kB) that indicates your tolerance for discarding
change by adding it to the fee (default: 0.0001). Note: An output
is discarded if it is dust at this rate, but we will always
discard up to the dust relay fee and a discard fee above that is
limited by the fee estimate for the longest target
.HP
\fB\-mintxfee=\fR<amt>
.IP
Fees (in LTC/kB) smaller than this are considered zero fee for
transaction creation (default: 0.001)
.HP
\fB\-paytxfee=\fR<amt>
.IP
Fee (in LTC/kB) to add to transactions you send (default: 0.00)
.HP
\fB\-rescan\fR
.IP
Rescan the block chain for missing wallet transactions on startup
.HP
\fB\-salvagewallet\fR
.IP
Attempt to recover private keys from a corrupt wallet on startup
.HP
\fB\-spendzeroconfchange\fR
.IP
Spend unconfirmed change when sending transactions (default: 1)
.HP
\fB\-txconfirmtarget=\fR<n>
.IP
If paytxfee is not set, include enough fee so transactions begin
confirmation on average within n blocks (default: 6)
.HP
\fB\-usehd\fR
.IP
Use hierarchical deterministic key generation (HD) after BIP32. Only has
effect during wallet creation/first start (default: 1)
.HP
\fB\-walletrbf\fR
.IP
Send transactions with full\-RBF opt\-in enabled (default: 0)
.HP
\fB\-upgradewallet\fR
.IP
Upgrade wallet to latest format on startup
.HP
\fB\-wallet=\fR<file>
.IP
Specify wallet file (within data directory) (default: wallet.dat)
.HP
\fB\-walletbroadcast\fR
.IP
Make the wallet broadcast transactions (default: 1)
.HP
\fB\-walletnotify=\fR<cmd>
.IP
Execute command when a wallet transaction changes (%s in cmd is replaced
by TxID)
.HP
\fB\-zapwallettxes=\fR<mode>
.IP
Delete all wallet transactions and only recover those parts of the
blockchain through \fB\-rescan\fR on startup (1 = keep tx meta data e.g.
account owner and payment request information, 2 = drop tx meta
data)
.PP
ZeroMQ notification options:
.HP
\fB\-zmqpubhashblock=\fR<address>
.IP
Enable publish hash block in <address>
.HP
\fB\-zmqpubhashtx=\fR<address>
.IP
Enable publish hash transaction in <address>
.HP
\fB\-zmqpubrawblock=\fR<address>
.IP
Enable publish raw block in <address>
.HP
\fB\-zmqpubrawtx=\fR<address>
.IP
Enable publish raw transaction in <address>
.PP
Debugging/Testing options:
.HP
\fB\-uacomment=\fR<cmt>
.IP
Append comment to the user agent string
.HP
\fB\-debug=\fR<category>
.IP
Output debugging information (default: 0, supplying <category> is
optional). If <category> is not supplied or if <category> = 1,
output all debugging information. <category> can be: net, tor,
mempool, http, bench, zmq, db, rpc, estimatefee, addrman,
selectcoins, reindex, cmpctblock, rand, prune, proxy, mempoolrej,
libevent, coindb, qt, leveldb.
.HP
\fB\-debugexclude=\fR<category>
.IP
Exclude debugging information for a category. Can be used in conjunction
with \fB\-debug\fR=\fI\,1\/\fR to output debug logs for all categories except one
or more specified categories.
.HP
\fB\-help\-debug\fR
.IP
Show all debugging options (usage: \fB\-\-help\fR \fB\-help\-debug\fR)
.HP
\fB\-logips\fR
.IP
Include IP addresses in debug output (default: 0)
.HP
\fB\-logtimestamps\fR
.IP
Prepend debug output with timestamp (default: 1)
.HP
\fB\-maxtxfee=\fR<amt>
.IP
Maximum total fees (in LTC) to use in a single wallet transaction or raw
transaction; setting this too low may abort large transactions
(default: 0.10)
.HP
\fB\-printtoconsole\fR
.IP
Send trace/debug info to console instead of debug.log file
.HP
\fB\-shrinkdebugfile\fR
.IP
Shrink debug.log file on client startup (default: 1 when no \fB\-debug\fR)
.PP
Chain selection options:
.HP
\fB\-testnet\fR
.IP
Use the test chain
.PP
Node relay options:
.HP
\fB\-bytespersigop\fR
.IP
Equivalent bytes per sigop in transactions for relay and mining
(default: 20)
.HP
\fB\-datacarrier\fR
.IP
Relay and mine data carrier transactions (default: 1)
.HP
\fB\-datacarriersize\fR
.IP
Maximum size of data in data carrier transactions we relay and mine
(default: 83)
.HP
\fB\-mempoolreplacement\fR
.IP
Enable transaction replacement in the memory pool (default: 1)
.HP
\fB\-minrelaytxfee=\fR<amt>
.IP
Fees (in BTC/kB) smaller than this are considered zero fee for relaying,
mining and transaction creation (default: 0.00001)
.HP
\fB\-whitelistrelay\fR
.IP
Accept relayed transactions received from whitelisted peers even when
not relaying transactions (default: 1)
.HP
\fB\-whitelistforcerelay\fR
.IP
Force relay of transactions from whitelisted peers even if they violate
local relay policy (default: 1)
.PP
Block creation options:
.HP
\fB\-blockmaxweight=\fR<n>
.IP
Set maximum BIP141 block weight (default: 3000000)
.HP
\fB\-blockmaxsize=\fR<n>
.IP
Set maximum block size in bytes (default: 750000)
.HP
\fB\-blockmintxfee=\fR<amt>
.IP
Set lowest fee rate (in LTC/kB) for transactions to be included in block
creation. (default: 0.00001)
.PP
RPC server options:
.HP
\fB\-server\fR
.IP
Accept command line and JSON\-RPC commands
.HP
\fB\-rest\fR
.IP
Accept public REST requests (default: 0)
.HP
\fB\-rpcbind=\fR<addr>[:port]
.IP
Bind to given address to listen for JSON\-RPC connections. This option is
ignored unless \fB\-rpcallowip\fR is also passed. Port is optional and
overrides \fB\-rpcport\fR. Use [host]:port notation for IPv6. This
option can be specified multiple times (default: 127.0.0.1 and
::1 i.e., localhost, or if \fB\-rpcallowip\fR has been specified,
0.0.0.0 and :: i.e., all addresses)
.HP
\fB\-rpccookiefile=\fR<loc>
.IP
Location of the auth cookie (default: data dir)
.HP
\fB\-rpcuser=\fR<user>
.IP
Username for JSON\-RPC connections
.HP
\fB\-rpcpassword=\fR<pw>
.IP
Password for JSON\-RPC connections
.HP
\fB\-rpcauth=\fR<userpw>
.IP
Username and hashed password for JSON\-RPC connections. The field
<userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. A
canonical python script is included in share/rpcuser. The client
then connects normally using the
rpcuser=<USERNAME>/rpcpassword=<PASSWORD> pair of arguments. This
option can be specified multiple times
.HP
\fB\-rpcport=\fR<port>
.IP
Listen for JSON\-RPC connections on <port> (default: 9332 or testnet:
19332)
.HP
\fB\-rpcallowip=\fR<ip>
.IP
Allow JSON\-RPC connections from specified source. Valid for <ip> are a
single IP (e.g. 1.2.3.4), a network/netmask (e.g.
1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This
option can be specified multiple times
.HP
\fB\-rpcserialversion\fR
.IP
Sets the serialization of raw transaction or block hex returned in
non\-verbose mode, non\-segwit(0) or segwit(1) (default: 1)
.HP
\fB\-rpcthreads=\fR<n>
.IP
Set the number of threads to service RPC calls (default: 4)
.SH COPYRIGHT
Copyright (C) 2009-2017 The Bitcoin Core developers
Copyright (C) 2011-2017 The Litecoin Core developers
Please contribute if you find Litecoin Core useful. Visit
<https://litecoin.org> for further information about the software.
The source code is available from <https://github.com/floblockchain/flo>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>
This product includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit <https://www.openssl.org> and cryptographic software written by
Eric Young and UPnP software written by Thomas Bernard.

4
doc/reduce-traffic.md
View File

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

34
doc/release-notes-litecoin.md → doc/release-notes-flo.md
View File

@ -1,9 +1,9 @@
(note: this is a temporary file, to be added-to by anybody, and moved to
release-notes at release time)
Litecoin Core version *0.15.0* is now available from:
FLO Core version *0.15.0* is now available from:
<https://download.litecoin.org/litecoin-0.15.0/>
<https://flo.cash>
This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.
@ -14,15 +14,15 @@ Please report bugs using the issue tracker at GitHub:
To receive security and update notifications, please subscribe to:
<https://groups.google.com/forum/#!forum/litecoin-dev>
<https://groups.google.com/forum/#!forum/flo-dev>
How to Upgrade
==============
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Litecoin-Qt` (on Mac)
or `litecoind`/`litecoin-qt` (on Linux).
installer (on Windows) or just copy over `/Applications/FLO-Qt` (on Mac)
or `flod`/`flo-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,
@ -51,10 +51,10 @@ processing the entire blockchain.
Compatibility
==============
Litecoin Core is extensively tested on multiple operating systems using
FLO 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
FLO Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes
@ -119,7 +119,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 FLO 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
@ -138,17 +138,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.
FLO 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 FLO, either on the command line or in the FLO 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 FLO-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:
FLO Core 0.15.0 contains the following changes to the RPC interface and `flo-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 FLO Core with a single wallet, there are **no** changes to the RPC interface or `flo-cli`. All RPC calls and `flo-cli` commands continue to work as before.
* When running FLO 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 `flo-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 FLO 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:7312/wallet/wallet1.dat/`. `flo-cli` commands should be run with a `-rpcwallet` option, for example `flo-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.
@ -156,7 +156,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 FLO 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. FLO 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.
@ -189,7 +189,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 FLO 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

48
doc/tor.md
View File

@ -1,16 +1,16 @@
TOR SUPPORT IN LITECOIN
TOR SUPPORT IN FLO
======================
It is possible to run Litecoin as a Tor hidden service, and connect to such services.
It is possible to run FLO 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 flo behind a Tor proxy
---------------------------------
The first step is running Litecoin behind a Tor proxy. This will already make all
The first step is running FLO behind a Tor proxy. This will already make all
outgoing connections be anonymized, but more is possible.
-proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy
@ -31,27 +31,27 @@ outgoing connections be anonymized, but more is possible.
In a typical situation, this suffices to run behind a Tor proxy:
./litecoin -proxy=127.0.0.1:9050
./flo -proxy=127.0.0.1:9050
2. Run a litecoin hidden server
2. Run a flo hidden server
------------------------------
If you configure your Tor system accordingly, it is possible to make your node also
reachable from the Tor network. Add these lines to your /etc/tor/torrc (or equivalent
config file):
HiddenServiceDir /var/lib/tor/litecoin-service/
HiddenServicePort 9333 127.0.0.1:9333
HiddenServicePort 19335 127.0.0.1:19335
HiddenServiceDir /var/lib/tor/flo-service/
HiddenServicePort 7313 127.0.0.1:7313
HiddenServicePort 17313 127.0.0.1:17313
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 flod's P2P listen port (7313 by default).
-externalip=X You can tell litecoin about its publicly reachable address using
-externalip=X You can tell flo 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/flo-service/hostname. Onion addresses are given
preference for your node to advertise itself with, for connections
coming from unroutable addresses (such as 127.0.0.1, where the
Tor proxy typically runs).
@ -68,49 +68,49 @@ your litecoind's P2P listen port (9333 by default).
In a typical situation, where you're only reachable via Tor, this should suffice:
./litecoind -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen
./flod -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen
(obviously, replace the Onion address with your own). It should be noted that you still
listen on all devices and another node could establish a clearnet connection, when knowing
your address. To mitigate this, additionally bind the address of your Tor proxy:
./litecoind ... -bind=127.0.0.1
./flod ... -bind=127.0.0.1
If you don't care too much about hiding your node, and want to be reachable on IPv4
as well, use `discover` instead:
./litecoind ... -discover
./flod ... -discover
and open port 9333 on your firewall (or use -upnp).
and open port 7313 on your firewall (or use -upnp).
If you only want to use Tor to reach onion addresses, but not use it as a proxy
for normal IPv4/IPv6 communication, use:
./litecoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover
./flo -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover
3. Automatically listen on Tor
--------------------------------
Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
API, to create and destroy 'ephemeral' hidden services programmatically.
Litecoin Core has been updated to make use of this.
FLO Core has been updated to make use of this.
This means that if Tor is running (and proper authentication has been configured),
Litecoin Core automatically creates a hidden service to listen on. This will positively
FLO Core automatically creates a hidden service to listen on. This will positively
affect the number of available .onion nodes.
This new feature is enabled by default if Litecoin Core is listening (`-listen`), and
This new feature is enabled by default if FLO Core is listening (`-listen`), and
requires a Tor connection to work. It can be explicitly disabled with `-listenonion=0`
and, if not disabled, configured using the `-torcontrol` and `-torpassword` settings.
To show verbose debugging information, pass `-debug=tor`.
Connecting to Tor's control socket API requires one of two authentication methods to be
configured. For cookie authentication the user running litecoind must have write access
configured. For cookie authentication the user running flod must have write access
to the `CookieAuthFile` specified in Tor configuration. In some cases this is
preconfigured and the creation of a hidden service is automatic. If permission problems
are seen with `-debug=tor` they can be resolved by adding both the user running tor and
the user running litecoind to the same group and setting permissions appropriately. On
Debian-based systems the user running litecoind can be added to the debian-tor group,
the user running flod to the same group and setting permissions appropriately. On
Debian-based systems the user running flod can be added to the debian-tor group,
which has the appropriate permissions. An alternative authentication method is the use
of the `-torpassword` flag and a `hash-password` which can be enabled and specified in
Tor configuration.
@ -118,7 +118,7 @@ Tor configuration.
4. Privacy recommendations
---------------------------
- Do not add anything but litecoin ports to the hidden service created in section 2.
- Do not add anything but flo ports to the hidden service created in section 2.
If you run a web service too, create a new hidden service for that.
Otherwise it is trivial to link them, which may reduce privacy. Hidden
services created automatically (as in section 3) always have only one port

2
doc/travis-ci.md
View File

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

20
doc/zmq.md
View File

@ -5,8 +5,8 @@ connections, inter-process communication, and shared-memory,
providing various message-oriented semantics such as publish/subscribe,
request/reply, and push/pull.
The Litecoin Core daemon can be configured to act as a trusted "border
router", implementing the litecoin wire protocol and relay, making
The FLO Core daemon can be configured to act as a trusted "border
router", implementing the flo wire protocol and relay, making
consensus decisions, maintaining the local blockchain database,
broadcasting locally generated transactions into the network, and
providing a queryable RPC interface to interact on a polled basis for
@ -33,7 +33,7 @@ buffering or reassembly.
## Prerequisites
The ZeroMQ feature in Litecoin Core requires ZeroMQ API version 4.x or
The ZeroMQ feature in FLO Core requires ZeroMQ API version 4.x or
newer. Typically, it is packaged by distributions as something like
*libzmq3-dev*. The C++ wrapper for ZeroMQ is *not* needed.
@ -45,7 +45,7 @@ operation.
By default, the ZeroMQ feature is automatically compiled in if the
necessary prerequisites are found. To disable, use --disable-zmq
during the *configure* step of building litecoind:
during the *configure* step of building flod:
$ ./configure --disable-zmq (other options)
@ -66,8 +66,8 @@ address. The same address can be used in more than one notification.
For instance:
$ litecoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
-zmqpubrawtx=ipc:///tmp/litecoind.tx.raw
$ flod -zmqpubhashtx=tcp://127.0.0.1:28332 \
-zmqpubrawtx=ipc:///tmp/flod.tx.raw
Each PUB notification has a topic and body, where the header
corresponds to the notification type. For instance, for the
@ -75,7 +75,7 @@ notification `-zmqpubhashtx` the topic is `hashtx` (no null
terminator) and the body is the hexadecimal transaction hash (32
bytes).
These options can also be provided in litecoin.conf.
These options can also be provided in flo.conf.
ZeroMQ endpoint specifiers for TCP (and others) are documented in the
[ZeroMQ API](http://api.zeromq.org/4-0:_start).
@ -87,9 +87,9 @@ arriving. Please see `contrib/zmq/zmq_sub.py` for a working example.
## Remarks
From the perspective of litecoind, the ZeroMQ socket is write-only; PUB
From the perspective of flod, the ZeroMQ socket is write-only; PUB
sockets don't even have a read function. Thus, there is no state
introduced into litecoind directly. Furthermore, no information is
introduced into flod directly. Furthermore, no information is
broadcast that wasn't already received from the public P2P network.
No authentication or authorization is done on connecting clients; it
@ -102,5 +102,5 @@ retrieve the chain from the last known block to the new tip.
There are several possibilities that ZMQ notification can get lost
during transmission depending on the communication type your are
using. Litecoind appends an up-counting sequence number to each
using. FLOd appends an up-counting sequence number to each
notification which allows listeners to detect lost notifications.

2
src/consensus/params.h
View File

@ -62,7 +62,7 @@ struct Params {
uint256 nMinimumChainWork;
uint256 defaultAssumeValid;
// Florincoin: Difficulty adjustment forks.
// FLO: Difficulty adjustment forks.
int64_t TargetTimespan(int height) const {
// V1
if (height < nHeight_Difficulty_Version2)