Ixian SDK
Class Hierarchy
This inheritance list is sorted roughly, but not completely, alphabetically:
[detail level 12]
 CIXICore.Meta.ActivityAn activity item which describes a potentially interesting event on the DLT or S2 network
 CIXICore.AddressIxian Wallet Address. This class holds a binary value of an Ixian Address and contains functions to encode that information to- or retrieve it from a bytestream. An address can be constructed either directly from address bytes or from a combination of public key and a 'nonce' value
 CIXICore.AddressClientAllows a client to generated a secret value with incorporated markers for multiple addresses. Such a value obscures which addresses it represents, but allows others to check whether a given address is part of the set or not with a configurable degree of false-positives. See also AddressMatcher
 CIXICore.AddressMatcherThe other half of the implementation for AddressClient, which allows an untrusted party to check if given addresses are of interest to the client. The client supplies a 'matcher' value, against which the addresses are checked. The matcher will produce false-positives, but never false-negatives, which means that it is impossible to accurately determine if an address belongs to the client or not
 CIXICore.BlockAn Ixian DLT Block. A block contains all the transactions which act on the WalletState and various checksums which validate the actions performed on the blockchain. Blocks are the fundamental data structure of Distributed Ledger Technology (DLT) and form a chain of valid states from the so-called 'Genesis Block' to the present moment. An Ixian Block must include checksums of the previous block, checksums of the internal data structures (WalletState) and a list of transactions which have updated the WalletState from its previous value to its current value. In addition, a block contains cryptographic signatures of Master nodes, which is the basis for the Ixian Consensus algorithm
 CIXICore.BlockHeaderAn Ixian DLT Block Header. A block header contains the minimum required data needed for transaction inclusion verification
 CIXICore.ConsensusConfigBasic Ixian (compile-time) configuration values
 CIXICore.CoreA collection of utility functions
 CIXICore.CoreConfigBasic Ixian (compile-time) configuration values
 CIXICore.CoreProtocolMessageCommon functions for manipulating Ixian protocol message
 CIXICore.CryptoShortcuts for some common Ixian cryptographic operations
 CIXICore.ICryptoLibInterface for implementing different cryptographic libraries
 CIXICore.Network.IPAndMaskRepresents an IP address and a subnet mask
 CIXICore.Network.IPv4SubnetHelper class to help filter and classify IPv4 addresses
 CIXICore.IxianKeyPairRepresents the raw data of an Ixian RSA key value
 CIXICore.CryptoKey.KeyDerivationClass is able to deterministically generate child RSA keys from a pool of random data. Note: Please do not put this into production until a crypto-expert takes a look at it. This falls under the heading "Roll your own crypto". The problem is that C# and Java (android) - and possibly iOS - implementations do not provide a way to do this. In some cases it's possible to substitute the random generator for something like Sha512/t digest, but the core RSA generation algorithm is implemented differently. That means generating RSA keys from the same starting point would yield different results on different platforms. Furthermore, implementations may change in the future, which would break all key derivation. I see no other way than to implement this ourselves, so that we have control over when we change it and appropriately handle legacy cases
 CIXICore.Meta.LoggingA singleton class which gathers and stores all logging messages from the Ixian executable. It supports log rotation (on restart, or when reaching a certain size), outputting to the console and file simultaneously, automatic timestamping and thread identification. The actual work on the log files is done in a separate thread, so that the caller does not feel a performance impact for logging
 CIXICore.Utils.MnemonicA .NET implementation of the Bitcoin Improvement Proposal - 39 (BIP39) BIP39 specification used as reference located here: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Made by thash.nosp@m.izne.nosp@m.ts@ya.nosp@m.hoo..nosp@m.com.a.nosp@m.u v1.0.1.1 I ♥ Bitcoin :) Bitcoin:1ETQjMkR1NNh4jwLuN5LxY7bMsHC9PUPSV
 CIXICore.Transaction.MultisigAddrAddAnother allowed signer is being added to a Wallet. If the target wallet is not yet a 'Multi-Signature' wallet, it will be converted into one and the number of required signatures will be set to 1
 CIXICore.Transaction.MultisigAddrDelAn allowed signer is being removed from a Wallet. If the target wallet is not a 'Multi-Signature' wallet, such a transaction is considered invalid. The original Wallet's owner cannot be removed
 CIXICore.Transaction.MultisigChSigChange the number of required signatures for a 'Multi-Signature' wallet
 CIXICore.Transaction.MultisigTxDataAdditional signature for an existing MultisigTX transaction that is waiting in the pool
 CIXICore.Network.NetOpsDataHelper structure which holds a single IP addresses on which the server component is listening. Used only to communicate the configuration to the server listening thread
 CIXICore.Network.NetworkServerIxian network server object. This is used to accept connections from Ixian clients or other nodes and recieve Ixian protocol messages. Basic protocol validation is performed before a specialized protocol parser is called
 CIXICore.PeerA network peer (remote endpoint)
 CIXICore.PlatformPlatform-specific utilities
 CIXICore.Network.NetworkClientImplementation of the RemoteEndpoint interface as an Ixian network client
 CIXICore.Meta.ThreadLiveCheckHelper object to help diagnose and detect deadlocked threads
 CIXICore.TransactionRepresents a single transaction on the Ixian blockchain