Blockchain for Production NOT Speculation
Despite Bitcoin turning out to be a Big Con, the original design of Bitcoin technology does have some good features that we have made use of in Interval Chain.
Despite Bitcoin turning out to be a Big Con, the original design of Bitcoin technology does have some good features that we have made use of in Interval Chain.
Interval Chain is based on the already battle tested Bitcoin technology (the Multichain implementation) but WITHOUT the greed and ignorance driving Bitcoin's growth.
Interval Chain does NOT use the slow and energy wasting "proof of work" design.
Although we do NOT use "proof of work", a lot of the other features of the original Bitcoin protocol are still relevant to us.
Understanding how Bitcoin technology works is the first step in understanding one of the major building blocks of Interval Chain.
Bitcoin: A Peer-to-Peer Electronic Cash System - Satoshi Nakamoto
bitcoin.pdf (180.0 KB)
Bitcoin multisig the hard way: Understanding raw P2SH multisig transactions
Blockchain inefficiency in the Bitcoin peers network | EPJ Data Science | Full Text
https://sites.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/bitcoin-delay
All Multichain nodes are FULL nodes, unlike Bitcoin or Ethereum, MultiChain does NOT provide:
All nodes stores everything except offchain items of streams it does not subscribe to.
Interval Record secured via a distributed ledger (currently based on Multichain (which is a Bitcoin Core Fork).
The distributed ledger is normally blockchain based but is blockchain design agnostic, currently its uses the open sourced multichain.com software which is a fork of the battle proven Bitcoin Core software, however most other blockchain implementations can be used.
The version of Bitcoin Core used by multichain.com was forked at version 0.10 with patches from later versions applied as appropriate by multichain.com. Note we are talking about the multichain.com software which has NOTHING to do with multichain.org nor multichain.xyz
Interval Chain makes use of some open sourced Bitcoin Core technologies, otherwise it has nothing to do with the Bitcoin network. We are just reusing parts of the Bitcoin Core software to build our storage nodes. We could have used Ethereum etc. instead, but we are starting with Bitcoin Core as it is simpler for what we wanted to do initially.
Interval Chain uses features from Bitcoin Core as well as extra features added by Multichain:.
Blockchain Parameters:
https://www.multichain.com/developers/blockchain-parameters/
Runtime Parameters:
https://www.multichain.com/developers/runtime-parameters/
Scroll up and sideways within the boxes to see all parameters.
CHAIN OPTIONS
=============
Chain Options:
-alertnotify=<cmd> Execute command when a relevant alert is received or we see a really long fork (%s in cmd is replaced by message)
-blocknotify=<cmd> Execute command when the best block changes (%s in cmd is replaced by block hash)
-checkblocks=<n> How many blocks to check at startup (default: 288, 0 = all)
-checklevel=<n> How thorough the block verification of -checkblocks is (0-4, default: 3)
-conf=<file> Specify configuration file
-daemon Run in the background as a daemon and accept commands
-datadir=<dir> Specify data directory
-dbcache=<n> Set database cache size in megabytes (4 to 4096, default: 100)
-loadblock=<file> Imports blocks from external blk000??.dat file on startup
-loadblockmaxsize=<n> Maximal block size in the files specified in -loadblock
-maxorphantx=<n> Keep at most <n> unconnectable transactions in memory (default: 50000)
-par=<n> Set the number of script verification threads (-4 to 16, 0 = auto, <0 = leave that many cores free, default: 0)
-pid=<file> Specify pid file
-reindex Rebuild the blockchain and reindex transactions on startup.
-shortoutput Returns connection string if this node can start or default address otherwise
-txindex=0|1 Maintain a full transaction index, used by the getrawtransaction rpc call (default: 1)
Block creation options:
-gen=0|1 Generate coins (default: 1)
-genproclimit=<n> Set the number of threads for coin generation if enabled (-1 = all cores, default: 1)
-blockmaxsize=<n> Set maximum block size in bytes
Runtime parameters
-offline Start in offline mode, no connections to other nodes.
-storeruntimeparams Permanently save modifications to runtime parameters made by setruntimeparam APIs.
-initprivkey=<privkey> Manually set the wallet default address and private key when running for the first time.
-handshakelocal=<address> Manually override the wallet address which is used for handshaking with other peers in a blockchain.
-lockadminminerounds=<n> If set overrides lock-admin-mine-rounds blockchain setting.
-miningrequirespeers If set overrides mining-requires-peers blockchain setting, values 0/1.
-mineemptyrounds=<n> If set overrides mine-empty-rounds blockchain setting, values 0.0-1000.0 or -1.
-miningturnover=<n> If set overrides mining-turnover blockchain setting, values 0-1.
-shrinkdebugfilesize=<n> If shrinkdebugfile is 1, this controls the size of the debug file. Whenever the debug.log file reaches over 5 times this number of bytes, it is reduced back down to this size.
-shortoutput Only show the node address (if connecting was successful) or an address in the wallet (if connect permissions must be granted by another node)
-bantx=<txids> Comma delimited list of banned transactions.
-lockblock=<hash> Blocks on branches without this block will be rejected
-chunkquerytimeout=<n> Timeout, after which undelivered chunk is moved to the end of the chunk queue, default 25s
-chunkrequesttimeout=<n> Timeout, after which chunk request is dropped and another source is tried, default 10s
-flushsourcechunks=0|1 Flush offchain items created by this node to disk immediately when created, default 1
-acceptfiltertimeout=<n> Timeout, after which filter execution will be aborted, when accepting new txs, in milliseconds, default 100
-sendfiltertimeout=<n> Timeout, after which filter execution will be aborted, when tx is sent from this node, in milliseconds, default 20
-lockinlinemetadata=0|1 Outputs with inline metadata can be sent only using create/appendrawtransaction, default 1
-purgemethod=<method> Overwrite data before purging. Available modes: unlink, simple(=zero, default), one, zeroone, random1-random4, dod, doe, rcmp, gutmann.
NETWORK OPTIONS
===============
Connection options:
-addnode=<ip> Add a node to connect to and attempt to keep the connection open
-banscore=<n> Threshold for disconnecting misbehaving peers (default: 100)
-bantime=<n> Number of seconds to keep misbehaving peers from reconnecting (default: 86400)
-bind=<addr> Bind to given address and always listen on it. Use [host]:port notation for IPv6
-connect=<ip> Connect only to the specified node(s)
-discover=0|1 Discover own IP address (default: 1 when listening and no -externalip)
-dns=0|1 Allow DNS lookups for -addnode, -seednode and -connect (default: 1)
-dnsseed=0|1 Query for peer addresses via DNS lookup, if low on addresses (default: 1 unless -connect)
-externalip=<ip> Specify your own public address
-forcednsseed Always query for peer addresses via DNS lookup (default: 0)
-listen=0|1 Accept connections from outside (default: 1 if no -proxy or -connect)
-maxconnections=<n> Maintain at most <n> connections to peers (default: 125)
-maxoutconnections=<n> Open at most <n> outbound connections to peers (1-32, default: 8)
-maxreceivebuffer=<n> Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000)
-maxsendbuffer=<n> Maximum per-connection send buffer, <n>*1000 bytes (default: 100000)
-onion=<ip:port> Use separate SOCKS5 proxy to reach peers via Tor hidden services (default: -proxy)
-onlynet=<net> Only connect to nodes in network <net> (ipv4, ipv6 or onion)
-permitbaremultisig Relay non-P2SH multisig (default: 1)
-port=<port> Listen for connections on <port>
-proxy=<ip:port> Connect through SOCKS5 proxy
-seednode=<ip> Connect to a node to retrieve peer addresses, and disconnect
-timeout=<n> Specify connection timeout in milliseconds (minimum: 1, default: 5000)
-retryinittime=<n> Number of seconds during which an initial connection is retried before the node quits (default: 0)
-whitebind=<addr> Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
-whitelist=<netmask> Whitelist peers connecting from the given netmask or IP address. 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
RPC server options:
-server=0|1 Accept command line and JSON-RPC commands
-rest Accept public REST requests (default: 0)
-rpcbind=<addr> Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)
-rpcuser=<user> Username for JSON-RPC connections
-rpcpassword=<pw> Password for JSON-RPC connections
-rpcport=<port> Listen for JSON-RPC connections on <port>
-rpcallowip=<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
-rpcallowmethod=<methods> If specified, allow only comma delimited list of JSON-RPC <methods>. This option can be specified multiple times.
-rpcthreads=<n> Set the number of threads to service RPC calls (default: 4)
-rpckeepalive RPC support for HTTP persistent connections (default: 0)
RPC SSL options
-rpcssl Use OpenSSL (https) for JSON-RPC connections
-rpcsslcertificatechainfile=<file.cert> Server certificate file (default: server.cert)
-rpcsslprivatekeyfile=<file.pem> Server private key (default: server.pem)
-rpcsslciphers=<ciphers> Acceptable ciphers (default: TLSv1.2+HIGH:TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH)
API response parameters
-hideknownopdrops Remove recognised OP_DROP metadata from the responses to JSON-RPC calls (default: 0)
-maxshowndata=<n> The maximum number of bytes to show in the data field of API responses. (default: 16384)
Pieces of data larger than this will be returned as an object with txid, vout and size fields, for use with the gettxoutdata command.
-maxqueryscanitems=<n> The maximum number of txs to be decoded during JSON-RPC querying commands. (default: 5000)
WALLET OPTIONS
==============
Wallet options:
-keypool=<n> Set key pool size to <n> (default: 1)
-paytxfee=<amt> Fee (in BTC/kB) to add to transactions you send (default: 0.00)
-rescan Rescan the block chain for missing wallet transactions on startup
-salvagewallet Attempt to recover private keys from a corrupt wallet.dat on startup
-skipwalletchecks Skip wallet consistency verification on startup
-sendfreetransactions Send transactions as zero-fee transactions if possible (default: 0)
-spendzeroconfchange=0|1 Spend unconfirmed change when sending transactions (default: 1)
-txconfirmtarget=0|1 If paytxfee is not set, include enough fee so transactions begin confirmation on average within n blocks (default: 1)
-maxtxfee=<amt> Maximum total fees to use in a single wallet transaction, setting too low may abort large transactions (default: 0.10)
-wallet=<file> Specify wallet file (within data directory) (default: wallet.dat)
-walletnotify=<cmd> Execute this command when a transaction is first seen or confirmed, if it relates to an address in the wallet or a subscribed asset or stream.
-walletnotifynew=<cmd> Execute this command when a transaction is first seen, if it relates to an address in the wallet or a subscribed asset or stream.
(more details and % substitutions online)
-walletdbversion=2|3 Specify wallet version, 2 - Berkeley DB, 3 (default) - proprietary
-autosubscribe=<params> Automatically subscribe to new streams and/or assets, as a comma dlimited list of subscriptions.
-zapwallettxes=<mode> Delete all wallet transactions and only recover those parts of the blockchain through -rescan on startup
(1 = keep tx meta data e.g. account owner and payment request information, 2 = drop tx meta data)
Wallet optimization options:
-autocombineminconf=<n> Only automatically combine outputs with at least this number of confirmations, default 1
-autocombinemininputs=<n> Minimum inputs in automatically created combine transaction, default 50
-autocombinemaxinputs=<n> Maximum inputs in automatically created combine transaction, default 100
-autocombinedelay=<n> Minimium delay between two auto-combine transactions, in seconds, default 1
-autocombinesuspend=<n> Auto-combine transaction delay after listunspent API call, in seconds, default 15
DEBUG OPTIONS
=============
Debugging/Testing options:
-debug=<category> Output debugging information (default: 0, supplying <category> is optional)
If <category> is not supplied, output all debugging information.
<category> can be: addrman, alert, bench, coindb, db, lock, rand, rpc, selectcoins, mempool, net,
mchn, mcblock, mcnet, mcminer, mcapi, wallet, filter, v8filter, chunks, offchain
-help-debug Show all debugging options (usage: --help -help-debug)
-logips Include IP addresses in debug output (default: 0)
-logtimestamps=0|1 Prepend debug output with timestamp (default: 1)
-limitfreerelay=<n> Continuously rate-limit free transactions to <n>*1000 bytes per minute (default:0)
-minrelaytxfee=<amt> Fees (in BTC/Kb) smaller than this are considered zero fee for relaying (default: 0.00001)
-printtoconsole Send trace/debug info to console instead of debug.log file
-logdir Send trace/debug info to specified directory
-shrinkdebugfile=0|1 Shrink debug.log file on client startup (default: 1 when no -debug)
The Multichain software is currently used to implement all 3 types of Interval Chains for the 25.5 release.
Minimum support version 2.3.3
Multichain has this concept of "subscription" to the a data stream, although ALL nodes already stores all the blockchain data, they can save some storage (those used for stream indexes and offchain items) by NOT subscribing to some streams within a blockchain.
With subscription they can easily query the stream and have access to the offchain content of the subscribed stream.
As of 2024-11--2 the latest 2.3.3 Multichain version has a scaling problem, there might be an upcoming release version 2.3.5 which might have a fix for it.
This does not affect Interval Chain, since Team Compute separate of powers and aggregation of resources principles means we need have many blockchains anyway.
Interval Chain has almost infinite scalability due to the large number of ways that data can be split up into multiple blockchains.
We use Multichain's Data Streams extensively to store our JSON data, so it is important to understand exactly how it works.
Multichain uses Google's LevelDB as database underneath, but LevelDB does NOT support secondary indices, so Multchain has to build its own "indices" to supports its the data stream's multiple key feature.
MultiChain stores all data in LevelDB using prefix-encoded keys, allowing it to efficiently simulate secondary indexes. For streams, the stream items are stored with keys like:
S:<stream-id>:<txid>
To support key-based lookup, MultiChain builds manual indexes, for example:
K:<stream-id>:<key>:<txid>
where:
S = raw stream item
K = index entry for key lookup
For example:
LevelDB Key Prefix | Value |
---|---|
S:stream1:tx123 |
stream item data |
K:stream1:temperature:tx123 |
pointer to S entry or summary |
K:stream1:device42:tx456 |
pointer to S entry or summary |
Each key-value pair in LevelDB is ordered lexicographically, so iterating over:
K:stream1:temperature:
allows for efficient key-based listing like liststreamkeyitems.
LevelDB uses "sorted lexicographical ordering" for fast scans with an internal log-structured merge tree (LSM tree).
Performance
Operation | Efficiency |
---|---|
Seek to key prefix | O(log N) |
Iterate matching keys | O(1) per match |
Full DB scan | O(N) — not done unless needed |
So prefix-based lookup (e.g. "K:stream1:temperature:") is actually quite fast.
Release 1.18
Multichain seems to be using LevelDB 1.18
This Multichain LevelDB was released back in Sep 17, 2014
Bitcoin Core's LevelDB has move to 1.22 released in May 4, 2019
The current latest LevelDB is 1.23 released back in Feb 24, 2021
1.18 is missing some of the newer features, but not too bad to use, we will keep it at this stage rather than forking Multichain.