diff --git a/taptrade-cli-demo/coordinator/.cookie b/taptrade-cli-demo/coordinator/.cookie new file mode 100644 index 0000000..345d1d0 --- /dev/null +++ b/taptrade-cli-demo/coordinator/.cookie @@ -0,0 +1 @@ +__cookie__:db7e210a348561c1afa367f9f7f021fdb74e0fc131944fb1fc892239c651184b \ No newline at end of file diff --git a/taptrade-cli-demo/coordinator/src/wallet/mod.rs b/taptrade-cli-demo/coordinator/src/wallet/mod.rs index 0fda0a9..8e8b7cb 100644 --- a/taptrade-cli-demo/coordinator/src/wallet/mod.rs +++ b/taptrade-cli-demo/coordinator/src/wallet/mod.rs @@ -57,7 +57,7 @@ pub fn init_coordinator_wallet() -> Result> { // wallet // .sync(&backend, SyncOptions::default()) - // .context("Connection to electrum server failed.")?; // we could also use Esplora to make this async + // .context("Connection to blockchain server failed.")?; // we could also use Esplora to make this async dbg!(wallet.get_balance()?); Ok(CoordinatorWallet { wallet: Arc::new(Mutex::new(wallet)), diff --git a/taptrade-cli-demo/rpc_node/regtest/data/bitcoin.conf b/taptrade-cli-demo/rpc_node/regtest/data/bitcoin.conf index f86f8f1..df70af3 100644 --- a/taptrade-cli-demo/rpc_node/regtest/data/bitcoin.conf +++ b/taptrade-cli-demo/rpc_node/regtest/data/bitcoin.conf @@ -15,4 +15,5 @@ regtest=1 [regtest] rpcbind=0.0.0.0 rpcallowip=0.0.0.0/0 -rpcport=8332 \ No newline at end of file +rpcport=8332 +port=18444 \ No newline at end of file diff --git a/taptrade-cli-demo/rpc_node/regtest/data/mine-blocks.sh b/taptrade-cli-demo/rpc_node/regtest/data/mine-blocks.sh index 1caeee4..17b5b1f 100644 --- a/taptrade-cli-demo/rpc_node/regtest/data/mine-blocks.sh +++ b/taptrade-cli-demo/rpc_node/regtest/data/mine-blocks.sh @@ -16,7 +16,7 @@ else fi # Generate initial blocks -bitcoin-cli -regtest -datadir="/home/bitcoin/.bitcoin" -generate 101 +bitcoin-cli -regtest -datadir="/home/bitcoin/.bitcoin" -rpcwallet="coordinator_wallet" -generate 101 # Generate a block every 300 seconds while true; do diff --git a/taptrade-cli-demo/rpc_node/regtest/docker-compose.yml b/taptrade-cli-demo/rpc_node/regtest/docker-compose.yml index 1c1c87e..701a9d4 100644 --- a/taptrade-cli-demo/rpc_node/regtest/docker-compose.yml +++ b/taptrade-cli-demo/rpc_node/regtest/docker-compose.yml @@ -4,21 +4,30 @@ services: container_name: bitcoin ports: - 8332:8332 + - 18444:18444 networks: - bitcoin volumes: - bitcoin:/home/bitcoin/.bitcoin - fulcrum: - build: ./fulcrum - container_name: fulcrum + electrs: + build: ./electrs + container_name: electrs ports: - - 5321:5321 + - 50001:50001 volumes: - - fulcrum-volume:/home/fulcrum/fulcrum_data + - bitcoin:/home/electrs networks: - bitcoin restart: always + environment: + - ELECTRS_DB_DIR=/home/electrs/db + - ELECTRS_ELECTRUM_RPC_ADDR=0.0.0.0:50001 + - ELECTRS_NETWORK=regtest + - ELECTRS_COOKIE_FILE=/home/electrs/.cookie + - ELECTRS_DAEMON_RPC_ADDR=bitcoin:8332 + - ELECTRS_DAEMON_P2P_ADDR=bitcoin:18444 + - ELECTRS_LOG_FILTERS=INFO depends_on: bitcoin: condition: service_started @@ -26,7 +35,6 @@ services: volumes: bitcoin: - fulcrum-volume: networks: bitcoin: diff --git a/taptrade-cli-demo/rpc_node/regtest/electrs/Dockerfile b/taptrade-cli-demo/rpc_node/regtest/electrs/Dockerfile new file mode 100644 index 0000000..058641c --- /dev/null +++ b/taptrade-cli-demo/rpc_node/regtest/electrs/Dockerfile @@ -0,0 +1,23 @@ +FROM debian:bookworm + +RUN apt update && apt install -y git bash vim clang cmake build-essential librocksdb-dev=7.8.3-2 cargo rustc + +RUN mkdir -p /home/electrs + +WORKDIR /home/electrs + +RUN git clone https://github.com/romanz/electrs --branch v0.10.5 --single-branch + +WORKDIR /home/electrs/electrs + +RUN ROCKSDB_INCLUDE_DIR=/usr/include ROCKSDB_LIB_DIR=/usr/lib cargo build --locked --release --no-default-features + +RUN mv /home/electrs/electrs/target/release/electrs /usr/local/bin + +WORKDIR /home/electrs + +RUN rm -rf /home/electrs/electrs + +RUN mkdir db + +CMD ["electrs"] \ No newline at end of file diff --git a/taptrade-cli-demo/rpc_node/regtest/fulcrum/Dockerfile b/taptrade-cli-demo/rpc_node/regtest/fulcrum/Dockerfile deleted file mode 100644 index dc06baf..0000000 --- a/taptrade-cli-demo/rpc_node/regtest/fulcrum/Dockerfile +++ /dev/null @@ -1,18 +0,0 @@ -FROM debian:latest - -RUN apt update - -RUN mkdir -p /home/fulcrum - -COPY ./fulcrum /home/fulcrum/. -COPY ./config.conf /home/fulcrum/. - -WORKDIR /home/fulcrum - -RUN mkdir fulcrum_data -RUN chmod +x ./fulcrum - -EXPOSE 5321 - -#CMD ["tail", "-f"] -CMD ["./fulcrum", "config.conf"] diff --git a/taptrade-cli-demo/rpc_node/regtest/fulcrum/config.conf b/taptrade-cli-demo/rpc_node/regtest/fulcrum/config.conf deleted file mode 100644 index 0a765fe..0000000 --- a/taptrade-cli-demo/rpc_node/regtest/fulcrum/config.conf +++ /dev/null @@ -1,1087 +0,0 @@ -# Fulcrum Sample Config File -# -# Feel free to edit this file (or a copy of it) and then pass it as a bare -# argument when starting Fulcrum, e.g.: -# -# $ ./Fulcrum myconfig.conf -# -# The configuration file format for Fulcrum resembles that of bitcoind.conf in -# that it is a simple name = value style file format, with comments denoted by -# `#` characters. Configuration variables are case insensitive and Fulcrum -# completely ignores variable names that it does not understand. -# -# Boolean variables (such as 'debug' or 'syslog' below) may be specified as name -# = 1, name = true, name = false, name = off, etc, or without any '=' sign in -# which case they are interpreted as "true". -# -# Some (but not all) configuration variables below have corresponding command- -# line equivalents (such as -D/--datadir, for example). If a configuration -# parameter is specified both in the conf file as well as the CLI, the CLI arg -# takes precedence and overrides the corresponding conf file parameter. In this -# way, it's possible to override the conf file for a particular run of Fulcrum -# while still "inheriting" the rest of the config file. Say you wanted to test -# Fulcrum against a different daemon, you would then do: -# -# $ ./Fulcrum myconfig.conf -b 192.168.1.23:45678 -# -# -# What follows below are commented-out versions (in many cases set to their -# defaults) of all of the variables you can use to customize the operation of -# Fulcrum. Required parameters have been left uncommented and must be specified -# for Fulcrum to operate correctly. - - -# ------------------------------------------------------------------------------ -# BASIC OPTIONS -#------------------------------------------------------------------------------- - -# Database directory - 'datadir' - REQUIRED -# -# Specifies the directory where to store the database. Be sure the directory is -# on a drive that has 35+ GB of space for mainnet or ~8GB of space for testnet. -# If the directory does not exist, it will be created. It is recommended you use -# an SSD, but an HDD will work as well once synched, however synching will take -# much longer on an HDD. -# -# NOTE: Use native path separators: '/' on Unix, '\' on Windows. -# -datadir = /home/fulcrum/fulcrum_data # Windows: datadir = D:\FulcrumData\mainnet - - -# Bitcoin daemon RPC host:port - 'bitcoind' - REQUIRED -# -# Specifies a hostname:port for connecting to the bitcoind rpc service. This is -# a required option (along with rpcuser and rpcpassword below). This -# hostname:port would be the same as you specified in your bitcoin.conf file -# under `rpcbind=` and `rpcport=`. -# -bitcoind = bitcoin:8332 - - -# Bitcoin daemon RPC username - 'rpcuser' - REQUIRED (unless rpccookie is specified) -# -# Specifies the username to use for authenticating to bitcoind. This is a -# required option, along with 'bitcoind' and 'rpcpassword'. This option should -# be the same username you specified in your bitcoind.conf file under -# `rpcuser=`. For security, you may want to omit this option from the config -# file and use the RPCUSER environment variable instead (however, the config -# file or any -u/--rpcuser CLI args will take precedence, so if you do want to -# use the environment variable scheme, then be sure to comment-out the below -# line). -# -rpcuser = coordinator - - -# Bitcoin daemon RPC password - 'rpcpassword' - REQUIRED (unless rpccookie is specified) -# -# Specifies the password to use for authenticating to bitcoind. This is a -# required option, along with 'bitcoind' and 'rpcuser'. This option should be -# the same password you specified in your bitcoind.conf file under -# `rpcpassword=`. For security, you may want to omit this option from the config -# file and use the RPCPASSWORD environment variable instead (however, the config -# file or any -p/--rpcpassword CLI args will take precedence, so if you do want -# to use the environment variable scheme, then be sure to comment-out the below -# line). -# -rpcpassword = test1234 - -# Bitcoin daemon RPC cookie file location - 'rpccookie' - DEFAULT: Not used -# -# An alternative to using rpcuser= and rpcpassword= is to use .cookie file -# authentication. This should the full path to your .cookie file in your -# bitcoind datadir. Do not specify this at the same time as "rpcuser" and -# "rpcpassword" -# -#rpccookie = /path/to/bitcoind/datadir/.cookie - - -# Bitcoin daemon poll interval - 'polltime' - DEFAULT: 2.0 seconds -# -# The number of seconds for the bitcoind poll interval. Bitcoind is polled once -# every `polltime` seconds to detect mempool and blockchain changes. This value -# must be at least 0.5 and cannot exceed 30. If not specified, the default is -# 2.0 seconds. -# -#polltime = 2.0 - - -# TCP bind - 'tcp' - DEFAULT: 0.0.0.0:50001 -# -# Specifies the TCP interface:port to bind to for Electron Cash clients to -# connect to. Default is 0.0.0.0:50001. Typically on the Electron Cash network -# 50001 & 50002 are for mainnet TCP & SSL and 60001 & 60002 are for testnet TCP -# & SSL, respectively. If you wish to bind to multiple ports, you may specify -# this option multiple times, once for each interface:port combination. -# -# Note: At the present time, outside of Tor proxying, Electron Cash clients -# typically do not like to connect to non-SSL servers -- so using just TCP will -# lead to not very many clients using your server. SSL is highly recommended. -# -# You may specify either IPv4 or IPv6 interfaces. -# -tcp = 0.0.0.0:5321 - - -# SSL bind - 'ssl' - DEFAULT: disabled (no SSL bind port) -# -# Specifies the SSL interface:port to bind to for Electron Cash clients to -# connect to. Default is to not use SSL. Typically on the Electron Cash network -# 50001 & 50002 are for mainnet TCP & SSL and 60001 & 60002 are for testnet TCP -# & SSL, respectively. If you wish to bind to multiple ports, you may specify -# this option multiple times, once for each interface:port combination. -# -# If you enable SSL you must also specify the 'cert' and 'key' configuration -# parameters (see below). -# -# You may specify either IPv4 or IPv6 interfaces. -# -#ssl = 0.0.0.0:50002 - - -# WS bind - 'ws' - DEFAULT: disabled (no WS bind port) -# -# Specifies the IPv4 or IPv6 interface:port to bind to for the Web Socket -# (ws://) port. Typically on the Electron Cash network 50003 & 50004 are for -# mainnet WS & WSS and 60003 & 60004 are for testnet WS & WSS, respectively. -# If you wish to bind to multiple ports, you may specify this option multiple -# times, once for each interface:port combination. -# -# You may specify either IPv4 or IPv6 interfaces. -# -#ws = 0.0.0.0:50003 - - -# WSS bind - 'wss' - DEFAULT: disabled (no WSS bind port) -# -# Specifies the IPv4 or IPv6 interface:port to bind to for the Web Socket Secure -# (wss://) port. Typically on the Electron Cash network 50003 & 50004 are for -# mainnet WS & WSS and 60003 & 60004 are for testnet WS & WSS, respectively. If -# you wish to bind to multiple ports, you may specify this option multiple -# times, once for each interface:port combination. -# -# If you enable WSS you must also specify the 'cert' and 'key' configuration -# parameters (see below). -# -# You may specify either IPv4 or IPv6 interfaces. -# -#wss = 0.0.0.0:50004 - - -# SSL certificate - 'cert' - DEFAULT: None (required for SSL) -# -# Specifies the SSL certificate to use for all SSL ports. The certificate must be -# in PEM format. If using self-signed certs, the .pem file should contain a -# single certificate. If using CA-signed certs, the .pem file should contain the -# full certificate chain (e.g. fullchain.pem). -# -#cert = /path/to/server-cert.pem - - -# SSL private key - 'key' - DEFAULT: None (required for SSL) -# -# Specifies the SSL private key to use for encryption. At the present time only -# RSA keys are fully supported. EC, DH, and DSA keys are supported, but their -# support is experimental. The file must be in PEM format. -# -#key = /path/to/server-key.pem - - -# WSS-specific certificate - 'wss-cert' - DEFAULT: None (recommended for WSS) -# -# Similar to `cert`, but will only be applied to `wss` ports. This parameter -# should be a CA-signed fullchain.pem file. This option is intended to allow WSS -# ports to use a CA-signed certificate (required by web browsers), whereas -# legacy Electrum Cash ports may want to continue to use self-signed -# certificates. If this option is specified, `wss-key` must also be specified. -# If this option is missing, then WSS ports will just fall-back to using the -# certificate specified by `cert`. -# -#wss-cert = /path/to/my-ca-signed-wss-fullchain.pem - - -# WSS-specific private key - 'wss-key' - DEFAULT: None (recommended for WSS) -# -# Similar parameter to `key`, but will only be applied to `wss` ports. Specify a -# private key PEM file to use for WSS. This key must go with the certificate -# specified in `wss-cert` above. If this option is specified, `wss-cert` must -# also be specified. -# -#wss-key = /path/to/my-ca-signed-wss-privkey.pem - - -# Admin RPC bind - 'admin' - DEFAULT: None -# -# Specifies the listen address and port for the admin RPC service. This service -# is used by the fulcrum_admin script to issue control commands to Fulcrum. As -# such, you should *NOT* bind to an interface and/or port that is publicly -# accessible by the rest of the internet. It is recommended that you bind to the -# loopback interface (e.g. 127.0.0.1 on IPv4). The port parameter used here can -# be given to the fulcrum_admin script via the -p arg. This option may be -# specified more than once to bind to multiple ports and/or interfaces. -# -#admin = 8000 # <-- a port number by itself implies 127.0.0.1 -#admin = 127.0.0.1:8000 - - -# HTTP stats bind - 'stats' - DEFAULT: None -# -# Specifies the listen address and port for the "stats" HTTP server. You may hit -# this endpoint with /stats in your browser, and it will serve you some -# JSON-encoded statistics. The /stats endpoint is intended as a convenient way -# to keep track of what your server is up to, how many clients are connected, -# what the load it is, etc. Do *NOT* expose this port to the public! It is for -# your admin use only! The default is to not start any "stats" HTTP servers -# unless you specify this option. This option may be specified more than once to -# bind to multiple ports and/or interfaces. -# -#stats = 8080 # <-- a port number by itself implies 127.0.0.1 -#stats = 127.0.0.1:8080 - - -# Syslog mode - 'syslog' - DEFAULT: off (false) -# -# Syslog mode. If on Unix, use the syslog() facility to produce log messages -# (rather than writing to stdout). This option currently has no effect on -# Windows. -# -#syslog = false - - -# Debug mode - 'debug' - DEFAULT: off for Release builds, on for Debug builds -# -# Specifies that logging should produce extra verbose output, which may be -# useful for diagnostics. This option is the inverse of the 'quiet' option (see -# below). You may specify either 'debug' or 'quiet', but not both. -# -# This option may be specified multiple times. In that case, network 'trace' -# output will also be generated (this is extremely verbose output typically only -# used for development and/or protocol-level troubleshooting.) -# -#debug = false - - -# Quiet mode - 'quiet' - DEFAULT: on for Release builds, off for Debug builds -# -# Limits logging to the normal messages, without any extra verbose debug info. -# This option is the inverse of the 'debug' option and is the default on release -# builds. You may specify either 'debug' or 'quiet', but not both. -# -quiet = true - - -# CheckDB at startup - 'checkdb' - DEFAULT: off (false) -# -# If enabled, database consistency will be checked thoroughly for sanity & -# integrity each time Fulcrum is (re)started. This may take anywhere from 30 -# seconds up to a few minutes depending on your system. Under normal operation -# these checks are not necessary but are provided as a debugging tool in case -# you suspect your database files may be corrupt. This also may be specified on -# the CLI via the --checkdb or -C option for a one-time check. -# -#checkdb = false - - -# Donation address - 'donation' -# - DEFAULT: bitcoincash:qplw0d304x9fshz420lkvys2jxup38m9symky6k028 -# -# The server donation address. This address is given to users when they select -# "Help -> Donate to server" from the Electron Cash GUI, and/or clients that -# invoke the "server.donation_address" RPC method. Additionally, it can also be -# used in the banner text file as the $DONATION_ADDRESS substitution variable -# (see the 'banner' conf variable below). No checks are done on the server side -# to ensure this is a valid Bitcoin Cash address, it is just relayed to clients -# verbatim as a text string (80 characters maximum). -# -# If unspecified, the default will be the developer's donation address. -# -donation = x@lnaddress.com - - -# Server banner text file - 'banner' -# - DEFAULT: Send a static string "Connected to a Fulcruim xx.x server" -# -# The "banner" text file to send to clients when they request the server banner. -# Specify a file path to a server-readable UTF-8 encoded text file (maximum file -# length: 16384 bytes). Typically Electron Cash clients ask for the server -# banner (via the "server.banner" RPC method) when they first connect to your -# server. They then display this text in the "Console" tab of the Electron Cash -# GUI. Some server admins get creative with this file and include ASCII or emoji -# art and other fancy features, while others choose to use the banner text to -# relay technical information about the server, or both. -# -# Banner text file variable substitution: -# -# The server banner text file supports variable substitutions. You may include -# the following special tokens (case sensitive) in your text file which will be -# interpreted and replaced with the appropriate text: -# -# $SERVER_VERSION - Server software version number, short. -# e.g.: "1.0" or "1.2", etc. -# $SERVER_SUBVERSION - Server software version, long. -# e.g.: "Fulcrum 1.0" -# $DAEMON_VERSION - BitcoinD version number, short. -# e.g.: "0.20.6" or "1.1.7" -# $DAEMON_SUBVERSION - BitcoinD daemon "subversion" useragent string. -# e.g.: "/Bitcoin ABC:0.20.6(EB32.0; Bobs_Server)/" -# $DONATION_ADDRESS - The server donation address as configured (see the -# section on the 'donation' conf variable). -# -#banner = /path/to/banner.txt - - -# Anonymize Client IP addresses and TxIDs in logs - 'anon_logs' - DEFAULT: false -# -# If true, client IP addresses and transaction IDs will be hidden from the -# "normal" log level. The "debug" or "trace" log levels may still contain this -# information in some cases. -# -anon_logs = true - - -#------------------------------------------------------------------------------- -# PEER DISCOVERY AND PUBLIC SERVER OPTIONS -#------------------------------------------------------------------------------- - -# Public hostname - 'hostname' - DEFAULT: Local IP address on server -# -# The server's public hostname. This is the hostname that your server will -# announce to clients and to other servers engaged in peer discovery. It is very -# important that you set this option, since if it is not set, the default is to -# just report your local IP address to other servers and to clients. In most -# cases this default is incorrect if your server is behind a firewall. What's -# more, this text is used to identify your server in the Electron Cash GUI, so -# the default will look like a non-human-friendly IP address, which is most -# certainly not what you want. For best results, set this option to the public -# hostname of your server as others would connect to it on the internet, -# preferably this hostname also matches the hostname in your SSL certificate -# (this latter consideration is not required just recommended). You may also -# wish to set 'public_tcp_port' and 'public_ssl_port' as well (see those -# sections in this file). -# -# hostname = s - - -# Public TCP port - 'public_tcp_port' - DEFAULT: The first 'tcp' port configured -# -# The server's public TCP port. This, along with 'hostname' and the various -# 'public_*_port' variables are announced to clients and to other servers -# engaged in peer discovery. The default for this variable is to simply use the -# first TCP port specified in the server configuration (if any). If you are -# behind a firewall and doing some port remapping, then you definitely want to -# set this option. This should be the public TCP port as would be used by the -# rest of the internet to connect to your server via an unencrypted TCP -# connection (non-SSL). You may also set this option to 0 to disable reporting -# any TCP port. -# -public_tcp_port = 0 - - -# Public SSL port - 'public_ssl_port' - DEFAULT: The first 'ssl' port configured -# -# The server's public SSL port. This, along with 'hostname' and the various -# 'public_*_port' variables are announced to clients and to other servers -# engaged in peer discovery. The default for this variable is to simply use the -# first SSL port specified in the server configuration (if any). If you are -# behind a firewall and doing some port remapping, then you definitely want to -# set this option. This should be the public SSL port as would be used by the -# rest of the internet to connect to your server via SSL. You may also set this -# option to 0 to disable reporting any SSL port. -# -public_ssl_port = 0 - - -# Public WS port - 'public_ws_port' - DEFAULT: The first 'ws' port configured -# -# The server's public WS (Web Socket) port. This, along with 'hostname' and the -# various 'public_*_port' variables are announced to clients and to other servers -# engaged in peer discovery. The default for this variable is to simply use the -# first WS port specified in the server configuration (if any). If you are -# behind a firewall and doing some port remapping, then you definitely want to -# set this option. This should be the public WS port as would be used by the -# rest of the internet to connect to your server via an unencrypted Web Socket -# (ws://) connection. You may also set this option to 0 to disable reporting any -# WS port. See also: ws, tor_ws_port -# -public_ws_port = 0 - - -# Public WSS port - 'public_wss_port' - DEFAULT: The first 'wss' port configured -# -# The server's public WSS (Web Socket Secure) port. This, along with 'hostname' -# and the various 'public_*_port' variables are announced to clients and to other -# servers engaged in peer discovery. The default for this variable is to simply -# use the first WSS port specified in the server configuration (if any). If you -# are behind a firewall and doing some port remapping, then you definitely want -# to set this option. This should be the public WSS port as would be used by the -# rest of the internet to connect to your server via an encrypted Web Socket -# Secure (wss://) connection. You may also set this option to 0 to disable -# reporting any WSS port. See also: wss, tor_wss_port -# -public_wss_port = 0 - - -# Peer discovery - 'peering' - DEFAULT: true -# -# If set, we query other servers for their peer list and attempt to reach out to -# new servers appearing on the network. Normally, Electron Cash clients will -# query your server asking it for its list of servers, so leaving this as true -# means you will be able to return meaningful results to clients about available -# servers on the network. -# -peering = false - - -# Peering: announce self - 'announce' - DEFAULT: true if hostname and peering -# are set, false otherwise -# -# You must enable `peering` above and also define a `hostname` for this to have -# an effect. If set to true and the above conditions are met, then your server -# will announce itself to peers and likely appear in their server lists. Setting -# this to true ensures you get more clients connecting to your server. -# -announce = false - - - -#------------------------------------------------------------------------------- -# TOR Configuration (optional) -#------------------------------------------------------------------------------- -# -# This section is optional but if tor_hostname is set and if at least one -# tor_*_port is specified, we will also announce ourselves on the Tor network -# (iff announce=true). Note Tor won't work unless you also configure a Tor -# proxy on your system, and with it, configure it to also offer a Tor hidden -# service. - - -# Tor hostname - 'tor_hostname' - DEFAULT: Nothing -# -# If specified, and if you have a Tor proxy configured, and if you have at least -# one of tor_tcp_port and/or tor_ssl_port specified, then we will anounce this -# host via Tor as a .onion host. Note that this hostname must end in .onion. -# -#tor_hostname=aykwhy6o2o4ixushlonpjooqv73fwx7jqgoreiknnqxuqv4dwffmb7qd.onion - - -# Tor banner - 'tor_banner' - DEFAULT: Use the regular banner -# -# Tor banner is optional. If unset, will just use the regular banner= setting -# (if any), or a fallback string "Connected to a Fulcrum xx.yy.zz server.". This -# is here in case you want an alternate banner to be shown to users connecting -# to your server via Tor. -# -#tor_banner=/path/to/another/alternate/banner_tor.txt - - -# Tor TCP port - 'tor_tcp_port' - DEFAULT: Nothing -# -# If set, we will advertise ourselves as living on the .onion tor_hostname above -# and offering this port for incoming TCP connections via Tor. At least one of -# the various tor_*_port variables must be set (along with tor_hostname) in -# order to announce this server via Tor. -# -# This option may not be specified multiple times. -# -#tor_tcp_port = 50001 - - -# Tor SSL port - 'tor_ssl_port' - DEFAULT: Nothing -# -# If set, we will advertise ourselves as living on the .onion tor_hostname above -# and offering this port for incoming SSL connections via Tor. At least one of -# the various tor_*_port variables must be set (along with tor_hostname) in -# order to announce this server via Tor. -# -# This option may not be specified multiple times. -# -#tor_ssl_port = 50002 - - -# Tor WS port - 'tor_ws_port' - DEFAULT: Nothing -# -# If set, we will advertise ourselves as living on the .onion tor_hostname above -# and offering this port for incoming WS connections via Tor. At least one of -# the various tor_*_port variables must be set (along with tor_hostname) in -# order to announce this server via Tor. -# -# This option may not be specified multiple times. -# -#tor_ws_port = 50003 - - -# Tor WSS port - 'tor_wss_port' - DEFAULT: Nothing -# -# If set, we will advertise ourselves as living on the .onion tor_hostname above -# and offering this port for incoming WSS connections via Tor. At least one of -# the various tor_*_port variables must be set (along with tor_hostname) in -# order to announce this server via Tor. -# -# This option may not be specified multiple times. -# -#tor_wss_port = 50004 - - -# Tor proxy to use for outbound connections - 'tor_proxy, tor_user, tor_pass' -# - DEFAULT: 127.0.0.1:9050, no username, no password -# -# If you want to discover .onion peers, be sure to configure a Tor daemon to -# run alongside your server. The default configuration is for the Tor proxy -# port to be 127.0.0.1:9050, no username, no password. If you modified the -# default in your torrc, then specify the settings used here so that Fulcrum -# may use the Tor proxy to discover .onion peers. -# -#tor_proxy = 9050 # e.g. localhost 9050. IP addr or hostname ok too: 10.0.0.1:9150, fooproxy.com:9050, etc. -#tor_user = # leave this out unless you specified a username in your torrc -#tor_pass = # leave this out unless you specified a password in your torrc - - - -#------------------------------------------------------------------------------- -# ADVANCED OPTIONS -#------------------------------------------------------------------------------- - -# BitcoinD number of clients - 'bitcoind_clients' - DEFAULT: 3 -# -# The number of simultaneous bitcoin RPC clients that we spawn to connect to -# bitcoind's RPC port. If you raise this value from the default, be sure to also -# specify the option `rpcthreads=` in bitcoind's conf file (or `-rpcthreads=` on -# the CLI) in order to raise the number of concurrent RPC threads that bitcoind -# uses from the default of 4. You may also want to raise the bitcoind -# `-rpcworkqueue=` parameter above the default of 16 as well. -# -# In general, if you are using a recent version of BCHN with its improved -# JSON-RPC performance, increasing this number (and the corresponding -# -rpcthreads option in bitcoind) may yield better parallelism during initial DB -# synch as well as better performance for your clients. This number should not -# exceed the number of cores in your system, however, as performance may suffer -# in that case. Note that Bitcoin Core doesn't parallelize very well on its -# `getblocks` call due to the way it holds a global lock throughout the entire -# call, so if you are on BTC, your mileage may vary with how much extra -# performance you can get from more simultaneous clients specified here. -# -#bitcoind_clients = 3 - - -# BitcoinD request throttling - 'bitcoind_throttle - DEFAULT: 50 20 5 -# -# This is an advanced parameter added to Fulcrum v1.0.4 to control and rate- -# limit client spamming of requests that hit bitcoind, e.g. -# 'blockchain.transaction.get'. The rationale for this facility is that it's -# possible for misbehaving clients to choke the system by hitting the server (in -# particular bitcoind) with many expensive, I/O-bound requests per unit time, -# which would degrade the responsiveness of the server to other clients. -# -# This parameter must be specified as a 3-tuple (whitespace or comma-delimited). -# The three items in the tuple are: "burst limit", "low water mark", and "decay -# per second" for the first, second, and third items, respectively. The -# definition of these three parameters is described below: -# -# "burst limit" - The number of simultaneous outstanding bitcoind-bound requests -# a client may send out at once. If a client has outstanding bitcoind-bound -# requests that have not yet returned results, and the number of such requests -# hits this limit, then the client will be throttled for at least 200 -# milliseconds, or until the "low water mark" of extant request is reached -# (whichever is longer). In other words, the throttling is achieved by pausing -# all further processing of requests for that client, until either 200 ms -# has elapsed or the "low-water mark" for outstanding requests (default 20) is -# hit. The default value (50) for this burst parameter is a decent value that is -# neither too liberal nor too conservative. -# -# "low water mark" - If a client is paused, then the number of requests that are -# outstanding to bitcoind must dip below this number before it is unpaused. -# -# "decay per second" - If a client has outstanding requests, and bitcoind has -# not replied in some time, "credit" the client with this many requests towards -# their burst, per second. -# -# These parameters may be queried and/or adjusted dynamically at runtime via the -# FulcrumAdmin 'bitcoind_throttle' command. -# -#bitcoind_throttle = 50 20 5 - - -# BitcoinD RPC Timeout - 'bitcoind_timeout' - DEFAULT: 30.0 -# -# The number of seconds to wait for unanswered bitcoind requests before we -# consider them as having timed-out. If the bitcoind we are connected to is in -# IBD, is on BCH ScaleNet, can be under high load, or is not on the same local -# machine, you may wish to set this to a higher value than the default. This -# value should be at least high enough to allow for time to prepare and download -# large blocks from bitcoind (this is particularly critical if bitcoind is not -# on the same local machine and the connection to it is not particularly fast). -# If you see the error message "bitcoind request timed out" in the log, you may -# wish to set this value higher than the default. -# -#bitcoind_timeout = 30.0 - - -# Bitcoin daemon RPC uses TLS (HTTPS) - 'bitcoind-tls' - DEFAULT: false -# -# If true, connect to the remote bitcoind via HTTPS rather than the usual HTTP. -# Historically, bitcoind supported only JSON-RPC over HTTP; however, some -# implementations such as bchd support HTTPS. If you are using Fulcrum with -# bchd, you either need to start bchd with the `notls` option, or you need to -# specify this option to Fulcrum. -# -#bitcoind-tls = false - - -# Daemon RPC Passthrough - 'daemon_passthrough_subnets' - DEFAULT: (None) -# -# Specify a comma-delimited list of subnets for which to allow the RPC method -# "daemon.passthrough". This RPC method is potentially dangerous for public -# servers and should only be used for private or trusted networks. It allows -# clients to directly issue RPC commands to the bitcoin daemon. -# -# Clients connecting from one of the subnets specified by this paremeter will -# be allowed to access this RPC method. The default is that no clients are -# allowed. -# -# Examples: 10.10.2.0/24, 128.0.0.0/8, 123.45./16, 99.74.0.0/16 -# -#daemon_passthrough_subnets = - - -# Keep RocksDB Log Files - 'db_keep_log_file_num' - DEFAULT: 5 -# -# The maximum number of database log files to keep around on disk, per database. -# Specify a value in the range 5, 20000. -# -# db_keep_log_file_num = 5 - - -# Max RocksDB Open Files - 'db_max_open_files' - DEFAULT: 40 -# -# The maximum number of database .sst files (table files) to keep open, per -# database (there are 6 databases altogether used in Fulcrum). This limit can be -# used if you know for a fact that your process ulimit is going to be below the -# number of files in the database. The database on main net may be anywhere from -# 500 to 1000 files total for all 6 databases. (As the database grows, new files -# are added.) -# -# Specify a setting of -1 for "unlimited", that is, to keep all database files -# open, so that their indexes remain cached and in memory. This may impact -# memory consumption but it is the fastest possible setting. -# -# See: https://github.com/facebook/rocksdb/wiki/Memory-usage-in-RocksDB#indexes-and-filter-blocks -# -# Specify -1 for unlimited, or a value in the range 20, 2147483648. -# -# db_max_open_files = 40 - - -# Max RocksDB Memory in MiB - 'db_mem' - DEFAULT: 512.0 -# -# Specifies roughly the maximum amount of memory to give to rocksdb. Larger -# values offer better performance, at the expense of memory consumption. Note -# that rocksb's memory consumption may sometimes exceed this value during high -# load; this setting is merely advisory. -# -# Specify a floating-point or integer value in MiB (1 MiB = 1048576 bytes) in -# the range 50 to 2^64. It is not advised to specify large values in excess of -# 50% of total system RAM. The default is a good settings, however even 256 -# works well on an SSD. If using an HDD for the datadir, you may want to set -# this value higher than the default. -# -# db_mem = 512.0 - - -# RocksDB use "fsync" - 'db_use_fsync' - DEFAULT: false -# -# This boolean value, if true, tells the rocksdb library to use fsync() calls as -# opposed to fdatasync(). fsync() is slower but works around some potential -# issues in older Linux kernels and the ext4 filesystem. -# -# From the rocksdb documentation: -# -# " By default, writes to stable storage use fdatasync (on platforms where this -# function is available). If this option is true, fsync is used instead. -# -# fsync and fdatasync are equally safe for our purposes and fdatasync is -# faster, so it is rarely necessary to set this option. It is provided as a -# workaround for kernel/filesystem bugs, such as one that affected datasync -# with ext4 in kernel versions prior to 3.7. " - rocksdb/options.h -# -# db_use_fsync = false - - -# Fast sync = 'fast-sync' - DEFAULT: 0 -# -# If specified, Fulcrum will use a UTXO Cache that consumes extra memory but -# syncs up to to 2X faster. To use this feature, you must specify a memory value -# in MB to allocate to the cache. It is recommended that you give this facility -# at least 2000 MB for it to really pay off, although any amount of memory given -# (minimum 200 MB) should be beneficial. Note that this feature is currently -# experimental and the tradeoffs are: it is faster because it avoids redundant -# disk I/O, however, this comes at the price of considerable memory consumption -# as well as a sync that is less resilient to crashes mid-sync. If the process -# is killed mid-sync, the database may become corrupt and lose UTXO data. Use -# this feature only if you are 100% sure that won't happen during a sync. -# Specify as much memory as you can, in MB, here, e.g.: 3000 to allocate 3000 MB -# (3 GB). The default is off (0). This option only takes effect on initial sync, -# otherwise this option has no effect. -# -#fast-sync = 0 - - -# Maximum batch size (per IP) - 'max_batch' - DEFAULT: 345 -# -# The maximum size of JSON-RPC batch requests to the server. Set this to 0 -# to unconditionally disable JSON-RPC batch requests server-wide. -# -# This configurable limit is in place as a DoS-prevention measure. If nonzero, -# this limit is applied to non-whitelisted clients (clients whose IP is not -# in `subnets_to_exclude_from_per_ip_limits`). -# -# The limit is a total limit for all batch requests active from a particular -# IP address. For example, if max_batch = 99, and there are 4 connections from -# a single IP address, with each client from that IP simultaneously sending a -# batch request of size 25, then it's possible for 1 or more of the requests -# to be rejected (100 > 99). -# -#max_batch = 345 - - -# Maximum transmission backlog size - 'max_buffer' - DEFAULT: 8000000 -# -# The maximum size in bytes of the transmission buffer "backlog" (send and -# receive) per client. This limit is a simple sanity check against DoS and/or -# misbehaving clients. -# -# As a client is sent data, it is expected that they will read it in time and -# not let it accumulate on the sending end. If the data backlog exceeds this -# size, then the client is automatically disconnected. The default chosen is a -# good size in practice, but if your server is serving up large address -# histories in excess of 55,000 transactions for a single address, and your -# clients are slow to read and consume this data, then you may want to increase -# this limit. -# -# Note that unlike ElectrumX or ElecronX, this variable does *not* limit the -# size of transaction histories that may be sent to clients. In fact, you may -# set this variable quite low and if clients can read data as it is generated, -# they may receive arbitrarily large histories from your server. -# -# You may not set this number below 64000 (64 KB) or in excess of 100000000 -# (100 MB). -# -# Note that as of Fulcrum 1.0.4, you may dynamically adjust this value for all -# connected clients using the 'maxbuffer' FulcrumAdmin command, and it will be -# applied immediately to all connected clients. -# -#max_buffer = 8000000 - - -# Max client connections per IP - 'max_clients_per_ip' - DEFAULT: 12 -# -# The maximum number of simultaneous client connections allowed per originating -# IP address. This is a simple DoS control measure to prevent excessive -# connections from 1 computer on the internet. When a client attempts to exceed -# this per-IP limit, connections past the limit will be refused. This DoS -# control measure may backfire, however, if you anticipate many users arriving -# from behind the same NATed IP address. In practice, this rarely happens, but -# if you anticipate that to be the case, feel free to set this parameter higher. -# -# A value <= 0 or an empty value will disable this limit entirely. -# -#max_clients_per_ip = 12 - - -# Max history - 'max_history' - DEFAULT: 125000 -# -# The maximum size of the transaction history for a particular address -# (scripthash) that the server will serve to clients, in terms of number of -# transactions. Addresses having a history exceeding this size will not -# participate in subscriptions (the history status returned will be null), and -# `get_history` and/or `listunspent` will return an empty list. From the point -# of view of a client asking for such a large history -- it will be as if the -# address in question has no history at all. -# -# Be careful increasing this limit. The default chosen is already quite generous -# with fewer than 0.0000001% of addresses on mainnet having histories in excess -# of this limit. -# -# This is a performance-saving measure designed to keep excessively large -# address histories from impacting the performance of the server and using up -# resources. Moreover, it can be argued that such users with such -# computationally expensive histories are better served running a full node -# themseleves, rather than relying on a public SPV server and/or light wallet -# system. -# -# Note that there are some addresses on the chain whose histories exceed 7.5 -# million transactions. Returning such a large history to clients and/or -# calculating the "status hash" for such a large history takes on the order of -# seconds, and can impact the experience of other users of your server if -# excessive requests are made for such large histories (if this limit were not -# in place). -# -# This value may be set to any positive integer in the range: [1000, 25000000]. -# -#max_history = 125000 - - -# Max pending connections - 'max_pending_connections' - DEFAULT: 60 -# -# The maximum number of connections that may be simultaneously "pending" before -# new client connections are refused due to the backlog. "Pending" here refers -# to new connections that come in from the OS's TCP/IP stack but haven't yet -# been properly accepted by this software. The default value is 60, which is -# already quite generous. This variable is exposed for troubleshooting and -# debugging purposes and does not normally need to be modified. Valid values are -# in the range: 10 to 9999. -# -#max_pending_connections = 60 - - -# Maximum reorg depth - 'max_reorg' - DEFAULT: 100 -# -# The maximum number of blocks we can rewind back on chain reorg. This setting -# defines how many block undo entries we store in the database. Setting this -# above value beyond the default allows for Fulcrum to support >100-block deep- -# reorgs without requiring a resynch, at the expense of some disk space. -# -# Older Fulcrum versions had this value hard-coded to 100, which is now the -# minimum value for this setting. The maximum value you can specify here is -# 500,000 which is an obscenely high value, since one normally doesn't -# anticipate switching to another chain whose most recent common ancestor block -# is >500,000 blocks deep. Note that large values here simply use up more disk -# space and may affect block synch time, but otherwise have no other negative -# effect. If you are on a test chain or are on a network where you anticipate -# reorgs larger than 100 blocks, you may wish to set this value higher than the -# default. -# -# Note: If you do set this number higher than the default, then using the same -# datadir with an older Fulcrum version may lead to wasted disk space, since -# versions of Fulcrum prior to 1.3.2 used a hard-coded value of 100 for -# max_reorg. As such, running a version of Fulcrum prior to 1.3.2 on a datadir -# set up with max_reorg > 100 may mean that the old Fulcrum version will not -# properly clean up old undo entries, thus wasting a little bit of disk space. -# (If you then run a newer Fulcrum version again, however, the situation will -# resolve itself at that time -- so it's not a huge deal; it just is worth -# mentioning here). -# -#max_reorg = 100 - - -# Maximum subscriptions (global limit) - 'max_subs' - DEFAULT: 10000000 -# -# The maximum number of simultaneous script hash subscription that the server -# supports. If more than this number of subscriptions is requested by clients -# (unlikely) then the server will refuse new subscription requests. It will then -# kick off a background task to find the most-subscribed IP address and kick all -# the clients coming from that IP, and then clean up the subscription table. -# -# This config parameter was added in Fulcrum 1.0.5 as a measure to prevent -# clients from potentially exhausting server resources. -# -#max_subs = 10000000 - - -# Maximum subscriptions (per-IP address) - 'max_subs_per_ip' - DEFAULT: 75000 -# -# The maximum number of script hash subscriptions per IP address. Note that IP -# addresses matching 'subnets_to_exclude_from_per_ip_limits' will not be -# subjected to this limit (they will still be subjected to the global 'max_subs' -# limit, however). -# -# If a client attempts to subscribe beyond this limit for all the connections -# coming from their IP address, it will receive an error message. -# -#max_subs_per_ip = 75000 - - -# Peer IP uniqueness enforcement - 'peering_enforce_unique_ip' - DEFAULT: true -# -# If true (the default) we reject duplicate peers that appear multiple times -# under different hostnames but using the same IP address. Only the first such -# peer is accepted and all the others are rejected and do not appear in your -# server's peer list. This is a sybil attack defense measure and likely you -# should leave it as true. -# -#peering_enforce_unique_ip = true - - -# Use the fast simdjson JSON parser - 'simdjson' - DEFAULT: true -# -# If specified, enable or disable the new simdjson backend for JSON parsing. -# Simdjson is over 2x faster than the original parser, but since this parser was -# recently added, some users may wish to use the old parser. You may do so by -# spacifying `false` here. This option corresponds to the CLI argument -# `--no-simdjson` which has the negated meaning of this option. -# -#simdjson = true - - -# Exclusion from per-IP limits - 'subnets_to_exclude_from_per_ip_limits' -# - DEFAULT: 127.0.0.1/32, ::1/128 -# -# Specify a comma-delimited list of subnets to exclude from the per-IP limits -# (such as max_clients_per_ip). Clients connecting from one of these subnets -# will not be subjected to any per-IP limits. The default is for any clients -# connecting from localhost (this default is particularly useful if serving via -# Tor, where all clients come from localhost). Set this to the empty string to -# not have any excluded subnets, eg "subnets_to_exclude_from_per_ip_limits =". -# -# Examples: 10.10.2.0/24, 128.101.0.0/16, 123.45., 99.74.0.0/255.255.0.0, ... -# -#subnets_to_exclude_from_per_ip_limits = 127.0.0.1/32, ::1/128 - - -# Disallow deprecated TLS versions - 'tls-disallow-deprecated' - DEFAULT: false -# -# If true, restricts the TLS protocol used by the server to non-deprecated v1.2 -# or newer, disallowing connections from clients requesting TLS v1.1 or earlier. -# This option applies to all SSL and WSS ports server-wide. -# -#tls-disallow-deprecated = false - - -# Log timestamp format - 'ts-format' - DEFAULT: localtime -# -# Specify the log timestamp format, one of: none, uptime, localtime, utc. If -# unspecified, the default is "localtime". Before this option was introduced, -# previous versions of Fulcrum always logged using "uptime". -# -#ts-format = localtime -# - - -# Tx hash cache size MB - 'txhash_cache' - DEFAULT: 128 -# -# Specifies the amount of memory in MB to use for the txhash cache. The txhash -# cache is used to speed up processing for get_merkle, get_history, listunspent, -# and subscribe requests. -# -# On a memory-constrained system you may wish to lower this value, at the -# expense of server responsiveness (lower limit: 20 MB). On a large memory -# system, you may wish to raise this value, to increase server responsiveness -# (upper limit: 2000 MB). -# -# To view the current state of the txhash cache (which is actually divided up -# into 2 separate caches), use the FulcrumAdmin `getinfo` command. The caches -# appear under "storage_stats" -> "caches" and are labelled with the string -# "TxHash" appearing somewhere in their names. -# -#txhash_cache = 128 - - -# Work queue size - 'workqueue' - DEFAULT: 15000 -# -# The maximum size of the work queue. Requests from clients that require further -# processing (such as get_merkle, get_history, listunspent, etc) all end up -# being placed in a queue and processed asynchronously by threads in a thread -# pool. The 'workqueue' parameter sets the size of the work backlog before the -# server returns errors to clients. Normally this option does not need to be -# changed, but the parameter is exposed to server admins for testing and -# debugging purposes. -# -# It is an error to set this parameter to less than 10. -# -#workqueue = 15000 - - -# Work queue threads - 'worker_threads' - DEFAULT: 0 (= autodetect # of CPUs) -# -# The maximum number of worker threads that can simultaneously be spawned for -# work queue processing. In most cases you want to leave this option at its -# default (0, meaning autodetect to number of cores on the system), since using -# as many threads as there are cores on the system is the most efficient overall -# setting and leads to optimal server responsiveness and performance. -# -# In general as clients make requests they are processed very quickly and CPU -# impact on the server is minimal on average. You want the server to have access -# to all your cores for when work arrives in a burst -- which is why the default -# is a good setting. -# -# However, this configuration parameter is exposed to admins wishing to cap the -# maximal load that the server can put on the system. Say you have a server with -# 16 physical cores, setting 'worker_threads = 4' will cap the total CPU load on -# the system to 25% (4 out of 16 cores). -# -# You may even wish to experiment with setting this value higher than the number -# of cores on the system since some of the work submitted to the queue is I/O -# bound work (db reads from disk), so it may actually be beneficial to set this -# higher than the number of cores on the system. -# -#worker_threads = 0 # <--- autodetect to number of cores on the system. - - -# PID file - 'pidfile' - DEFAULT: None -# -# If specified, Fulcrum will write its process ID to this file on startup (and -# the file will be auto-deleted on app-shutdown). Enabling a PID file may be -# useful for admins wishing to integrate Fulcrum with monitoring software. -# -#pidfile = /path/to/fulcrum.pid - - - -#------------------------------------------------------------------------------- -# Reusable Payment Address (RPA) Options -#------------------------------------------------------------------------------- - -# Enable RPA indexing - `rpa` - DEFAULT: 1 for BCH, 0 for all other coins -# -# Whether or not to enable the BCH-specific "RPA" index. -# -# See: https://github.com/imaginaryusername/Reusable_specs/blob/master/reusable_addresses.md -# -# This index takes ~42M of space currently on mainnet (but may grow to >3GB as -# the blockchain advances over time). If this index is enabled, the -# `blockchain.rpa.*` and/or the `blockchain.reusable.*` RPC methods will be -# available to clients, and the `server.features` map will contain an "rpa" -# key to indicate that the server supports RPA. -# -# If unspecified, then the RPA index and associated RPCs will only be enabled -# for BCH, and will be disabled for all coins. -# -rpa = 0 - - -# RPA starting block height - `rpa_start_height` - DEFAULT: 825000 for mainnet -# 0 all other nets -# -# Limit the RPA index to start at this block height. Blocks before this height -# will not have their data indexed by the RPA index. The default for mainnet is -# to save space and cycles since before a certain block height, no RPA wallets -# were in existence anyway since RPA had not yet been invented. -# -#rpa_start_height = 825000 - - -# RPA history scan block limit - `rpa_history_blocks` - DEFAULT: 60 -# -# For the `blockchain.rpa.get_history` and/or `blockchain.reusable.get_history` -# RPC methods, limit the number of blocks that client can request to scan for RPA -# transactions in a single RPC call to this number of blocks. In other words, -# results will be truncated if the client requests a wider height range in their -# request than this number. The reason for this limit is that clients should be -# making many frequent fast calls to the server so as to maximize the server's -# ability to multiplex requests (many small requests is better than a few larger -# ones when it comes to perceived server responsiveness). Specifying this to be -# a large value (say, >1000) is a potential DoS vector. -# -#rpa_history_blocks = 60 - - -# RPA maximum history results limit - `rpa_max_history` - DEFAULT: `max_history` -# -# This is similar to the configuration option `max_history` (search for it above), -# but it can be independently specified for the RPA subsystem to be larger or -# smaller than the app-level `max_history`. If unspecified, this option will -# inherit whatever the app-level `max_history` setting is. -# -#rpa_max_history = 125000 - - -# RPA prefix bits minimum - `rpa_prefix_bits_min` - DEFAULT: 8 -# -# Affects the minimum "prefix" value that is accepted by the -# `blockchain.rpa.get_history` RPC method, in terms of number of bits. Specify -# a value in the range: [4, 16]. This is a low-level configuration variable and -# the default of 8 should be good for all extant RPA clients. 4 offers a larger -# anonymity set to clients when they perform queries (as they will get more -# haystack to their 1 needled they are looking for), but it comes with a -# performance penalty on the server-side, which is why we set the default -# minimum to 8 in Fulcrum. -# -#rpa_prefix_bits_min = 8 diff --git a/taptrade-cli-demo/rpc_node/regtest/fulcrum/fulcrum b/taptrade-cli-demo/rpc_node/regtest/fulcrum/fulcrum deleted file mode 100755 index b8a9da3..0000000 Binary files a/taptrade-cli-demo/rpc_node/regtest/fulcrum/fulcrum and /dev/null differ diff --git a/taptrade-cli-demo/trader/maker.env b/taptrade-cli-demo/trader/maker.env index 30e24f1..9e58dec 100644 --- a/taptrade-cli-demo/trader/maker.env +++ b/taptrade-cli-demo/trader/maker.env @@ -1,4 +1,4 @@ -ELECTRUM_ENDPOINT="ssl://mempool.space:60602" # signet electrum server +ELECTRUM_ENDPOINT="ssl://localhost:50001" # regtest electrum server COORDINATOR_ENDPOINT="http://127.0.0.1:9999" ROBOHASH_HEX="26ee3dee4815655d223c3505162fd4610294a9542f89bb3d3e9748f534ac10ae" # sha256 of "robot21" TRADE_TYPE="buy" diff --git a/taptrade-cli-demo/trader/taker.env b/taptrade-cli-demo/trader/taker.env index 48a0a57..67b07c3 100644 --- a/taptrade-cli-demo/trader/taker.env +++ b/taptrade-cli-demo/trader/taker.env @@ -1,4 +1,4 @@ -ELECTRUM_ENDPOINT="ssl://mempool.space:60602" # signet electrum server +ELECTRUM_ENDPOINT="ssl://localhost:50001" # signet electrum server COORDINATOR_ENDPOINT="http://127.0.0.1:9999" ROBOHASH_HEX="169b6049cf865eba7d01e1ad26975f1d5ff29d570297ff18d40a53c8281dff5d" # sha256 of "robot22" TRADE_TYPE="sell"