Interval Chain Tech

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.

Honest Bitcoin

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.

Bitcoin Core

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.

Technical Differences

All Multichain nodes are FULL nodes, unlike Bitcoin or Ethereum, MultiChain does NOT provide:

  • Pruned nodes - nodes that discard old block data after validating it.
  • SPV (Simplified Payment Verification) nodes - that rely on full nodes to validate for them.
  • Light clients - that only track specific streams or assets.

All nodes stores everything except offchain items of streams it does not subscribe to.

Interval Blockchain

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 Features

Interval Chain uses features from Bitcoin Core as well as extra features added by Multichain:.

  1. Cold Nodes
  2. Multi Signatures

Interval Chain Parameters

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)

bronze2024-aunsw0

Multichain Operation

The Multichain software is currently used to implement all 3 types of Interval Chains for the 25.5 release.

Installation

Minimum support version 2.3.3

Subscription

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.

Scaling Problem

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.

Multichain Database

We use Multichain's Data Streams extensively to store our JSON data, so it is important to understand exactly how it works.

Multiple Keys

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

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.