ixian technical white paper · ixian white paper 5 ixian distributed ledger technology ixian...

IXIAN WHITE PAPER

1

Technical White Paper

www.ixian.io [email protected]

http://www.ixian.io/

mailto:[email protected]

IXIAN WHITE PAPER

IXIAN Technical White Paper V 0.4

The Technical White Paper is a “live” document and is subject to change.

You can always find the latest version on www.ixian.io/whitepaper

Nov 2017

Authors (in no particular order):

Marko Arh-Tadič, project lead Damir Rekić, UX lead Marko Žagar, software architect Cristian Ciorba, lead developer Mina Kržišnik, legal & PR lead

http://www.ixian.io/whitepaper

http://www.linkedin.com/




IXIAN WHITE PAPER 1

Contents

Contents ..................................................................................................................................................... 1

Glossary ...................................................................................................................................................... 3

Quick “About” Project IXIAN ................................................................................................................ 4

IXIAN Distributed Ledger Technology ................................................................................................... 5

Use of IXIAN DLT for developers ....................................................................................................... 5

Use of IXIAN DLT for general public ................................................................................................. 6

IXIAN Secure Streaming Network .......................................................................................................... 6

Use of IXIAN S2 for general public .................................................................................................... 6

SPIXI Blockchain based Instant Messenger ........................................................................................... 7

Main features of SPIXI: ....................................................................................................................... 7

Use of SPIXI for general public .......................................................................................................... 7

IXIAN Technology – Technical Details ............................................................................................... 8

IXIAN DLT ............................................................................................................................................... 8

Blockchain and history ........................................................................................................................ 9

Included transactions ........................................................................................................................ 10

Invalid transactions ........................................................................................................................... 10

Wallet state in blockchain ................................................................................................................. 10

Transaction pool and accepting the new block ................................................................................ 11

Normal operation - graphical representation .................................................................................. 13

Begin new block calculation - graphical representation ................................................................. 14

Incoming block has fewer transactions – graphical representation ............................................... 15

Incoming block contains more transactions – graphical representation ....................................... 16

Incoming block is accepted by the network – graphical representation ........................................ 17

Blockchain rewards ........................................................................................................................... 18

Calculating the flat amount .............................................................................................................. 19

Awarding ............................................................................................................................................ 19

DLT API ............................................................................................................................................. 19

Algorithms .......................................................................................................................................... 20

IXIAN S2 – Secure Streaming Network ............................................................................................... 21

IXIAN WHITE PAPER 2

Presence List ...................................................................................................................................... 21

Presence List Authority .................................................................................................................... 21

PL Replication between Master nodes ............................................................................................. 21

Communication .................................................................................................................................. 22

Scale-out streaming ........................................................................................................................... 23

Stream payments: .............................................................................................................................. 23

Lack of trust ....................................................................................................................................... 24

Conclusion ............................................................................................................................................... 27

References ................................................................................................................................................ 28

IXIAN WHITE PAPER 3

Glossary

Node

Device connected to a network of other devices operating on the same protocol.

Distributed Ledger Technology (DLT)

DLT is a technology that allows data replication, sharing and synchronization across multiple

nodes. There is no central administrator, no centralized data storage and no single point of

failure.

Blockchain

Blockchain is a DLT that is used to maintain a continuously growing list of records, called

blocks. Each block contains a timestamp and a link to a previous block

Cryptocurrency/Cryptoasset

A digital asset designed to work as a medium of exchange using cryptography to secure the

transactions and to control the creation of additional units of the currency. Since it operates

in a trustless system it has no central authority and no single point of failure.

IXIAN Redacted blockchain (IXIAN DLT)

A Blockchain-like DLT that does not require full history of transactions/blocks for normal

operation.

IXIAN Instant Messenger (SPIXI)

Fully decentralized and secure instant messenger application, powered by IXIAN DLT and

IXIAN Network.

IXIAN Streaming Network (IXIAN S2)

A network consisting of IXIAN Nodes and IXIAN Redacted DLT Nodes

IXIAN Coin (IXI COIN)

Currency used for paying for services in IXIAN S2 and IXIAN DLT

IXIAN Wallet (IXI PAY)

An application, integrated in SPIXI, which is developed specifically to send and receive IXIs

and other cryptocurrencies as well.

IXIAN WHITE PAPER 4

Quick “About” Project IXIAN

The whole story of IXIAN, one that eventually lead to revolutionary and innovative products,

began on one hot Thursday afternoon. As an important discussion was taking place, the

unthinkable happened. The messaging service we were using went offline, stopping our

conversation immediately. Transferring to a different messaging service would have been a

very frustrating and time consuming effort, on top of that we didn't have access to our

discussions˙ message archive. The communication was essential for the work we were doing.

Given how such a relatively small nuisance caused a significant delay and compromised our

work, we concluded that a fast, secure and reliable messaging service was needed, and that

we should be the ones to develop it.

The original idea was to develop a centralized instant messaging app tailored to our needs,

however this solution turned out to be unfitting. A centralized app could never provide us

with the reliability, privacy, speed and security we needed and wanted. The option to develop

the application on one of the existing blockchain platforms seemed to be the way to go. After

testing various existing implementations, we’ve discovered a considerable amount of

limitations, prompting us to develop our own DLT.

Our ambitions though, were to be able to provide ourselves and others alike a unique yet

familiar experience - an instant messaging app where all the messages would be transferred

directly between the users in question, that sending messages through it would be secure and

fast. More to that, what if users would be able to order/pay/receive various digital services or

data? What if they could transfer money, provide/charge services, transfer all types of

sensitive data through this app, whilst being guaranteed security? It all amounted to an

overwhelming project, one that seemed a bit too ambitious at first. But one that we accepted

nonetheless.

IXIAN WHITE PAPER 5

IXIAN Distributed Ledger Technology

IXIAN Technology encompasses the environment and tools that will change the way we think

about blockchain technology.

IXIAN Redacted Blockchain or IXIAN Distributed ledger technology (IXIAN DLT) represents

an ambitious new concept that does not require full blockchain history in order to operate.

This is a significant feature, allowing IXIAN DLT to be several magnitudes smaller than that

of other blockchain technologies available today, such as Ethereum and Bitcoin.

The main advantages of the IXIAN DLT:

- Consensus-based block acceptance that allows the network to dynamically adjust the

requirement for block validity.

- Mathematically stable block validation. Acceptance of transactions and validation of

new blocks is confirmed quickly and efficiently using a deterministic lockstep

algorithm.

- Limited blockchain growth - IXIAN DLT will eliminate the need for a very large

blockchain.

- No proof-of-work required. The IXIAN DLT can function even with a very limited

processing power.

- Entire wallet state is linked to the current block. This is a unique advantage that

provides the ability to quickly see the current state of wallets even on low-powered

devices with limited bandwidth.

Use of IXIAN DLT for developers

Developers will be able to create their own coin on top of IXIAN DLT, having a fixed

conversion rate with IXI coin. Being one of the first blockchains that supports a fixed

conversion rate, we have taken great care that developers can integrate IXI coin in their

software, games, websites and more.

IXIAN WHITE PAPER 6

Use of IXIAN DLT for general public

Users will be able to transmit micro transactions. In practice this means that users will be

able to pay or receive transactions of small amounts, without paying an enormous or

disproportionate fees. An example of this is that a user can charge any fee (no matter how

small or big) for streamed content. This way users may reduce their streaming costs, stream

fast and securely and thus reach a wider net of potential clients.

IXIAN Secure Streaming Network

At the core of this project lies IXIAN streaming network, the sum of all connected software

clients. Using our revolutionary DLT, the network can establish direct connections between

users, on P2P principle and without any intermediaries. This allows its users a low-latency

and secure communication. Through the use of incentive-based relay nodes, the network can

maintain stability and optimize connections. Anyone that uses IXIAN S2 can operate as a

relay node, allowing every user to gather valuable IXI Coins while making the network

stronger. Now you can stream your photo, video or other content safe and fast.

Use of IXIAN S2 for general public

With IXIAN S2 users do not connect to a central server (as with other chat apps/services),

instead they connect directly to each other. This way they are able to transfer messages,

audios, videos and other data and money in a matter of seconds.

Why is this an advantage? Users do not have to pay for third party services and do not have

to worry about potential data leaks, privacy issues or even censorship. This is the core

function of our IXIAN S2.

Developers can use IXIAN S2 to build and monetize solutions that require secure streaming

capabilities. Services utilizing IXIAN S2 require smaller operating budgets and can as a

result be provided at a considerably lower cost compared to other alternatives.

IXIAN WHITE PAPER 7

SPIXI Blockchain based Instant Messenger

SPIXI is a truly decentralized, secure and private chat app that delivers an experience users

are familiar with, but still offers the highest level of security, privacy, simplicity, data and

money transfer, and more. Users have opportunity to ask for and charge for services and earn

money with a simple use of the integrated multi-cryptocurrency wallet. SPIXI maintains all

the basic features of the current chat apps, such as video calls, voice calls chats, image and

file transfer, group chat, and more.

Main features of SPIXI:

- reliable, with no downtime,

- custom distributed ledger technology for optimal decentralization,

- cryptographically secure messaging that offer the highest form of privacy and

security,

- end-to-end data streaming,

- multi-platform support,

- ability to buy and sell premium services directly within the app.

Use of SPIXI for general public

Users will enjoy completely private text and video chat, file and data transfer, money

transfer, content sharing and much more. All messages, data and transactions are securely

encrypted by ECDSA, a proven cryptographic method. Users will even be able to charge for

content and services (i.e. remote assistance, tarot reading, online tutoring, etc...).

IXIAN WHITE PAPER 8

IXIAN Technology – Technical Details

IXIAN DLT

This is a severely Redacted Blockchain, which is the core technology of the IXIAN network.

It enables IXIAN to integrate new nodes quickly and efficiently, with lesser strain on the

bandwidth than existing blockchain applications.

The basic tenets of the Redacted Blockchain are:

Severely reduced blockchain size: IXIAN blockchain aims to be several orders of

magnitude smaller than other offerings on the market, allowing usage on devices with

limited storage, such as Raspberry PI, embedded Atom, small, all-in-one servers. The

full IXIAN client (the wallet application) can run on smartphones, giving users

unprecedented, direct access to the blockchain without third-party intermediary

services.

Consensus-based block acceptance: Traditional blockchain validation determines

validity by the length of history – the longest chain of blocks is the canonically valid

one. While that approach has been proven to work in practice, IXIAN DLT employs a

consensus-based approach. This allows the network to dynamically adjust

requirement for block validity. The initial requirement is set at 75%.

Mathematically stable block validation: Acceptance of transactions and

validation of the new block can be calculated and reached by the majority of nodes

using an algorithmic approach known as deterministic lockstep. With a large part

of the network automatically reaching the same result, validity of the current block is

confirmed quickly and efficiently.

Limited blockchain growth: One of the larger problems with traditional systems

is growth of the blockchain. At the time of writing, Bitcoin chain weighs in at above

120GB, while Ethereum is already over 30GB. Plans to reduce the blockchain are

forming, but as of yet no practical solution has appeared. IXIAN’S DLT eliminates

this problem entirely.

IXIAN WHITE PAPER 9

No Proof-of-Work required: IXIAN DLT can function even with very limited

processing power. The operations, which are required to validate and accept the next

block, are sufficiently simple, so that even low-powered devices can participate as

Master Nodes. Simplicity is achieved by moving away from the customary “proof of

work” mining to a more efficient method of consensus.

Entire wallet state is linked to the current block: Currently accepted IXIAN

wallet state is a linked to the network’s previous block. This way, the exact balance of

all wallets is known as soon as the current state is synchronized. A unique advantage

this approach offers is the ability of any user to quickly see the exact, up-to-date state

of wallets, even on low-powered devices with limited bandwidth, such as mobile

phones, embedded computers, netbooks, …

Blockchain and history

In order to achieve its goals, IXIAN DLT does not store the entire history of blocks. This will

be possible if nodes choose to do so, but it will not mandatory for the operation of the network.

A protocol is in place to query the so-called “Full History Nodes” for any part of the

blockchain, which will enable verification of transactions all the way back to the Genesis

block. Storing history is entirely voluntary for any Master Node and is incentivized by

increasing mining rewards.

Several past blocks are always stored at each node. The DLT can dynamically adjust the

minimum number of stored past nodes depending on network conditions, number of

concurrent transactions, block size or other factors.

New nodes, joining the network will synchronize the latest state with their immediate

neighbors. This can be done very quickly due to the limited blockchain size. Because the

entire blockchain history is not normally available, new nodes have to trust the current

IXIAN DLT state. They can achieve this trust by verifying the signatures on the last valid

block, which must include the network-defined minimum number of Master node signatures

(initially 75%).

New blocks are generated by all nodes, based on the list of known transactions at the start of

the block generation cycle. These blocks are exchanged between neighboring nodes and

signed until the consensus limit is reached. After that, the block is immediately accepted by

the entire network.

IXIAN WHITE PAPER 10

Included transactions

Each new block includes transactions based on their timestamp value. A certain amount of

drift is permissible, since the clocks cannot be synchronized to arbitrary precision, but the

transaction timestamp serves as a fast, efficient initial filter. The list of included transactions

in the current block can change even while processing and is only finalized after the minimum

required signature number is achieved.

Any transactions, which do not make it into the current block (they are not included in the

accepted block) are returned to the queue and included in the next block. Thus, a possible

transaction confirmation delay of one block generation cycle can occur in some cases.

Invalid transactions

The validity of individual transactions is checked even before they are considered for

acceptance into the next block. Spending nonexistent funds or attempting to create a

transaction with incorrect signature is rejected outright by any honest node and is not

included in a block.

If a block, containing such a transaction, arrives, the signatures on the block will easily

pinpoint potentially bad (dishonest) nodes.

If two otherwise valid transactions being calculated in the current block are contradictory

(for example: double spending), the invalid transaction is selected by the timestamp – the

later transaction is dropped and the earlier one is confirmed. If the timestamps are exactly

the same, the algorithm chooses the transaction with the numerically lowest TX-id to keep.

With these definitions in place, all nodes can autonomously agree on which block is the

correct one.

Wallet state in blockchain

Because the full history is normally not visible, the currently valid DLT state also contains

the wallet status for all known addresses. This state is updated by each node, based on the

accepted next block using a variation of the deterministic lockstep mechanism. As an

implementation detail, only the checksum has to be communicated to neighbors to ensure

valid state.

If a node should arrive at an incorrect state checksum (compared to the majority of the

network), it has to re-initialize and download the state again. This procedure is the same as

when the node joins the network for the first time.


Transaction pool and accepting the new block

Transactions can be posted to any operational IXIAN DLT Node. The transaction is stored in

node’s local memory and communicated to its neighbors. The protocol allows for the same

transaction to be communicated to several nodes at once.

Each transaction is uniquely identified by a transaction identifier (TX-id).

Because of instantaneous re-transmission, the transactions quickly enter the local memory

storage of most nodes.

At certain time intervals (currently 30 seconds, but can be dynamically adjusted by the

network), the calculation of the next block begins. At this point, all nodes begin storing newly

arrived transactions in a temporary area, which eventually replaces the ‘current memory

pool’. Existing transaction pool is used to generate the next block. The transactions, which

are put into the new block, are selected based on their timestamp, within permissible drift.

Each node creates its own next block, consisting of:

- Checksum of the previous block

- Valid transactions for the new block

- Checksum of the entire new block (including previous block’s checksum)

- The node’s cryptographic signature of the block checksum.

These new blocks are then communicated to the node’s neighbors. During this process of

convergence, each Node accepts blocks from its neighbors. If the received block matches the

locally calculated one, the signature is already automatically correct (checksum matches).

If the incoming block does not match the local one, one of the following happens:

- If the incoming block has fewer transactions than the local block, no action is taken.

It is assumed that the sender of the smaller block will amend its status after it receives

and processes the larger block. If the local node has not yet done so, it may transmit

its own version of the current block back to the sender of the incomplete block.

- If the incoming block has more transactions than the local block, these missing

transactions are added. The validation and signature occurs again and the amended

block is transmitted to neighbors (it may be transmitted partially – only the missing

transactions and the new checksum+signature)


- If the incoming block has more than the network-defined lower limit of signatures,

the block is immediately accepted as valid. Transactions, which are part of the block

become confirmed. The node adds its signature to the block, thus accepting its validity.

The new block is written to storage and logically chained to the previous block. The

valid block (with the local node’s signature added) is transmitted to neighbors. (The

node only needs to send the checksum and its own signature to optimize bandwidth –

and only provide the full block on demand.) In the event that the local node has

transactions which did not make it into the valid block, these transactions are moved

to the temporary area and become part of the memory pool for the next block.

Next step:

After a block is accepted, the wallet state is updated and becomes part of the blockchain. The

temporary memory area with new transactions (and transactions, which didn’t make it into

the current block) becomes the new memory pool area and is re-synchronized to neighbors.

The process repeats each time a new block must be generated. The interval can be

dynamically adjusted by the network.


Normal operation - graphical representation

The IXIAN node is accepting transactions from clients. These transactions are immediately

relayed to neighbors and thus quickly propagate through the network. At this stage, the

transactions are in state ‘pending’.

Figure 1: Normal Operation – Diagram


Begin new block calculation - graphical representation

The node accepts the current transaction pool as valid for the next block. It generates

appropriate signatures and appends them to the finished block. New client transactions are

placed in a temporary area.

Figure 2: New Block Calculation – Diagram


Incoming block has fewer transactions – graphical representation

The neighboring node has sent a signed next block with fewer transactions. The number of

signatures on the new block is below minimum threshold for acceptance. The node sends the

missing transactions to the neighbor, so it can update its valid block.

Figure 3: Incoming Block Contains Fewer Transactions – Diagram


Incoming block contains more transactions – graphical representation

The new block, received from neighbor, has more transactions than the local block, but

minimum signature limit has not yet been reached. The local node updates its transaction

list and recalculated the proper checksums. The new transaction is also echoed to other

neighbors, who have already accepted the local node’s block.

Figure 4: Incoming Block Contains More Transactions Diagram


Incoming block is accepted by the network – graphical representation

The incoming block has enough signatures to become the next accepted block in the network.

If the incoming block contains new transactions, these are implicitly accepted. If the incoming

block does not contain some transactions, the extra transactions are moved to the temporary

area and (later) communicated to neighboring nodes. The accepted block is immediately

signed by the local node and communicated to neighboring blocks.

After accepting and forwarding the new block, the local node updates its state table and

verifies that it matches the checksum in the block. Then it returns to normal operation in

this way, the valid next block is immediately and quickly replicated across the network and

processing of blocks stops. Any transactions that weren’t accepted in the current block, are

placed at the top of the list for the next block. Temporary area is then used as the current

memory pool storage for the next block.

Figure 5: Incoming Block is Accepted by Network – Diagram


Blockchain rewards

In order to incentivize block generation and running of Master Nodes, IXIAN DLT proposes

two types of rewards both of which are granted to all participating Master nodes based

proportionally on the amount of IXIAN in their respective wallets.

- Transaction fees

Each transaction in the IXIAN DLT incurs a transaction fee. The fee amount can be

dynamically configured by the network based on current conditions, but hard limits

are imposed for both low and high values. The fee is proportional to transaction size,

but that is not a requirement of the network and can change during testing.

- Flat fee

On each block generation cycle, all wallets that have signed the previous block and

have a certain minimum balance (e.g.: > 1000) are given a flat amount of coins. This

currency is generated from nothing and provides a controlled inflation mechanism.

This represents the source of income for the network. Our plan is not to introduce a

final coin cap and instead control the inflation process to dynamically adapt to the

conditions of the market.

If a coin cap becomes required later, the flat fee can be revoked and Transaction Fee reward

can remain the only income to incentivize block mining.


Calculating the flat amount

The amount of flat fee to be awarded is calculated based on the desired level of inflation.

Since the inflation level is specified on a yearly basis, but awarded per block iteration, only a

certain fraction of the yearly inflation amount is generated with each cycle. The exact fraction

is a function of time elapsed since the ‘start1‘of the year.

Awarding

The total sum of both awards is added together and distributed to all Master nodes who have

participated in the previous block generation. The amount each node gets is proportional to

the balance in its wallet.

DLT API

In order to interface with the DLT software running on a particular node, a public API has

been developed and is made available to network clients based on configuration settings. A

JSON-based protocol is formalized and published in order to achieve certain functionality:

- Querying Node State;

- Querying Network State;

- Retrieving Wallet, Transaction and Block information;

- Retrieving Performance counters and statistics;

- Adjusting the operation of the Node;

- Posting new Transactions;

- Controlling the Node (shutdown, re-initialize, reconnect to network).

In order to use JSON as a communication protocol, the DLT software opens a TCP port (by

default listening only on the loopback interface). The binding address and port number are

configurable in the software settings.

11 The start and end time of the years here only means the currency inflation cycle and does

not have to align with the calendar year.


A client, which connects to the API port will send an HTTP request with a command. The

DLT software’s response will be returned in a JSON document as a HTTP response.

Specifications for all possible commands and their responses are published as part of the

IXIAN documentation.

This allows simple implementation of a GUI control application, which can run separately

from the DLT service, or even in a web-based interface.

In order to facilitate remote control, the DLT software only accepts commands, which

originate from a non-local IP address, if they contain a valid cryptographic signature. The

list of wallets, which are authorized to control the node, can be set in the configuration.

Algorithms

Security of IXIAN DLT largely depends on the security of the used hashing and encryption

algorithms. Creating our own cryptography was briefly considered, but such an endeavor is

highly discouraged without significant time and expertise in the field.

We have therefore decided to use industry-standard algorithms, which are currently

considered the safest. The protocol may, in the future, change these requirements if issues

are discovered or computing hardware makes breaking the encryption possible.

Here is a list of chosen cryptography and hashing algorithms for IXIAN DLT:

- Hash (Block checksum, Transaction checksum, various handshakes): SHA256

- Signature (Transaction sig, Block consensus signature, various handshakes): ECDSA

(curve: secp256k1)

- Encryption: AES (Rijndael)


IXIAN S2 – Secure Streaming Network

Presence List

The Presence List (PL) will be the core data structure for the IXIAN network. The goal of the

PL will be to store information about present nodes and clients in a form that allows efficient

updates.

The information stored in PL contains the following:

- Node Address (Naddr) – A unique address, generated by the node when it first initializes.

Proposed value for this field is the node public key (wallet address).

- IP – Combination of IPv4/IPv6 address and a port where the node is reachable. This

field may have multiple values.

- Node Type (NT) – A flag, indicating the type of connected node:

M – Master Node (manages presence list),

R – Relay Node,

D – Client, reachable directly on the listed IP,

C – Client, reachable through the relay node. In this case, IP field represents the relay

node IP,

- Last Seen Time (T) – Timestamp, when the last node communication occurred.

Presence List Authority

Presence List will only be updated by the Master nodes. All Relay nodes will be able to obtain

a current copy of the PL and keep it updated with an efficient protocol. Clients may opt to

download a partial PL from Relay nodes or Master nodes. A protocol will be in place to request

only specific information from the list.

PL Replication between Master nodes

Since Master nodes will be the only way the PL is updated, they will have to ensure fast and

accurate replication of all PL changes to all online Master nodes. This will be done via a

‘Recent Change List’, which will store recent updates to the PL, as received by the specific

Master Node. Other Relay or Master nodes may then specify a change id (hash) and only

download updates which occurred after the specified change.

If the requested change-id is obsolete (updates are no longer in the Recent Change List), the

other Node must re-download the entire PL.


Additionally, each update of the PL on a Master node will trigger a push update to other,

directly-connected Master nodes. Since change-id will uniquely identify the update, it may

be used to quickly discard updates which were already performed.

Updating the PL – relay nodes and clients

Relay nodes will also have a need to update the PL. For example, on connection or

disconnection of a client. The protocol will allow a Relay Node to send an update message to

one or more of the Master nodes. The change will then be added to the PL and propagated

between the Master nodes.

A Relay Node may add records for any connected client, with the IP field set to one of its own

public reachable addresses. A Relay Node can only delete or update a PL record for its own

clients (clients, whose IP field has one of the reachable addresses of the Relay node).

If a Relay Node would attempt to alter information, for which it is not authoritative, the

change would be rejected by the Master Node.

Communication

Trivial case

If at least one of the participating Clients is publicly connectable, the protocol will use direct

connection to transfer messages. In this eventuality, no network fees should be paid.

Connection through a relay

If both communicating parties are unable to establish a direct connection, a Relay Node will

have to be used. Transferring of messages through a Relay Node will be payable with IXIs

and will represents the main network income.


Scale-out streaming

If the data transmission is intended for multiple recipients (broadcast), the procedure will be

as follows:

- Consumers connect directly to the Content Originator (CO).

- If direct connection is not possible, or the CO reaches its transmission limit, a Relay

Node is employed:

o Content Originator chooses a nearby Relay Node (the choice can be random or

predetermined, if the CO controls several nodes).

o Content Originator begins streaming the broadcast data to the selected Relay

Node.

- The Presence List is updated to indicate that the broadcast stream has multiple

sources. The information includes source utilization estimate.

- Clients connect to the least utilized Relay to consume the broadcast. If the Relay Node

is over-utilized, or the Client cannot achieve the required bandwidth, the Client may

reconnect to a different Relay Node.

- If the utilization of all current Relay Nodes rises above a certain threshold, the CO

may add additional Relay Nodes. If the CO’s outbound bandwidth is unable to support

additional Relay Nodes, the broadcast may be ‘bounced’ through existing Relays.

- If overall utilization of the broadcast stream falls below a certain threshold, the least

utilized Relay Node stops broadcasting.

Stream payments:

Unlike payments for direct messages, broadcast streams are charged using a different model.

The initial (startup) cost of setting up Relay Nodes for the stream is paid by the Content

Originator. (If CO can meet client demand without using Relay Nodes, this payment does not

occur.)

Streams are paid per time intervals. Clients must place funds in a stream-escrow transaction

before the CO or a Relay Node will send the stream (data) to the client. After the time-period

is over, the client will be disconnected, unless a new stream-escrow transaction is created. In

this way, clients pay for paid broadcasts based on the amount of time they spend receiving.


There are several methods planned to prevent abuse:

- CO will encrypt the data stream and only provide keys to clients, when they pay for

the first time-slot.

- Relay nodes will only begin accepting and re-transmitting the stream after the startup

cost is paid.

- Relay nodes will track escrow transactions for their own clients in the DLT. If the

escrow is not paid for the new time-slot, they will disconnect the client.

- CO will pay Relay nodes according to their number of clients. If this payment is not

made within a certain grace period, the Relay will terminate the stream and

disconnect all its clients.

- A blacklist will be built and considered for all participating parties: CO, Relay nodes

and clients. Excessive errors, disconnections or non-payments will result in a network

ban (either permanent or temporary).

Lack of trust

Because the IXIAN DLT operates on the principle of least trust, measures need to be taken

to ensure honesty. The principal entities, which participate in a single message exchange are:

- CS – Sender (Client node)

- CR – Recipient (Client node)

- R – Relay Node

- IXIAN DLT

The main potential sources of dishonesty are as follows:

- Relay node – may attempt to claim reward without relaying the message, or may

attempt to relay a garbled message to induce retransmission.

- Recipient client – may receive the message and not confirm receipt, in an effort to

prevent the relay not from claiming the reward.

In order to ensure both the correct transmission and an honest payment, several steps have

to be taken.


Proposed is one of the procedures to ensure a fair transmission and payment, although this

method may be optimized or updated for the final version of the product2.

1. CS Prepares the message to send and a corresponding IXIAN DLT transaction. The

message is encrypted with the recipient's public key to ensure privacy. The DLT

transaction is in state 'pending' (no funds are transferred until validation). The DLT

transaction contains a known piece of information about the message (ie: the

checksum).

2. CS contacts one of the available relay nodes in order to start transmission.

3. R generates a one-time public/private keypair (because the protection of this key only

needs to last a short time, the keypair can be very short and thus generated quickly).

The public key is provided to CS.

4. CS additionally encrypts the message with the provided public key. Then it generates

a checksum, signing it using the same public key and appends it to the DLT

transaction. The encrypted message is sent to R.

5. R can verify that the message was really encrypted using the public key it provided,

since it has the corresponding private key. R can also verify that the correct signature

was written to the DLT.

6. R forwards the message, the one-time public key and the DLT transaction ID to CR.

7. CR can verify that the DLT transaction originated with CS. It can show this by adding

a checksum to the DLT transaction and signing it using the public key it was provided.

8. R releases the private part of the key, by providing it to CR and also adding it to the

DLT transaction.

9. CR can now decrypt the transmitted message with the one-time key. Then it can

decrypt the inner message using its permanent private key.

10. The nodes in the DLT network can confirm that the message transmission was

completed successfully, because the transaction in the Mem Pool contains the

following:

a) Cryptographic proof that CS originated the transaction.

2 The method is included as a proof of concept.


b) Signature, made with a public key from a temporary keypair.

c) Confirmation of receipt, by CR.

d) Private part of the temporary keypair, written by R.

With the above information, any DLT node can verify the identities of CS and CR, and also the

fact that the provided private key matches the public key.

Because the signature in point (b) was added by CS, who is incentivized by wanting to

transmit the message, this source cannot be doubted. (If CS lies, it will pay the transmission

costs without actually transmitting the message.)

By verifying the signature with the private key, which was added to the DLT transaction by

R, the DLT node can confirm that the private key really decrypts the provided signature.

R would not have added the private key, nor forwarded the message if CS attempted to lie by

using a different key to encrypt the message. (R can also verify this by decrypting the outer

layer of the message when it is received from CS.)

CR is incentivized to provide the correct verification of receipt, otherwise R would not release

the private part of the key.

Because R has to append the correct key to the DLT, in order for the transaction to be fully

verified, it cannot give CR the wrong key in order to try and force a retransmission. If it does,

CR can simply fetch the key from the DLT network.


Conclusion

We acknowledge that this is a world of plenty, where people value (or should value) time,

simplicity, privacy and security, while being socially responsible and preserving this planet.

We feel that we have a unique technology for everyone and for everyday use. The technology

is designed to transfer messages, money and data in a way that is easy, fast, secure and

green. Our true potential is in making the technology environmentally-responsible while

delivering an "IXITASTIC" experience for our users.


References

https://en.wikipedia.org/wiki/Blockchain

https://en.wikipedia.org/wiki/Distributed_ledger

https://en.wikipedia.org/wiki/Cryptocurrency

https://bittrex.com/


https://techcrunch.com/2017/04/12/messenger/

http://www.statisticbrain.com/skype-statistics/

http://expandedramblings.com/index.php/twitch-stats/

http://expandedramblings.com/index.php/whatsapp-statistics/

http://expandedramblings.com/index.php/how-many-people-use-chat-apps/

https://ring.cx/en/news#release-of-ring-10-liberte-egalite-fraternite

https://en.wikipedia.org/wiki/BlackBerry_Priv

https://blockchain.info/charts/blocks-size

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-

16-1-distributed-ledger-technology.pdf

https://www.quora.com/Why-isnt-the-size-of-the-blockchain-a-serious-problem-for-Bitcoin

http://www.dailystar.co.uk/tech/news/465903/SKYPE-DOWN-popular-messaging-service-

offline-across-globe

http://www.express.co.uk/life-style/science-technology/800092/WhatsApp-Down-Not-

Working-Outage-App-Update

https://en.wikipedia.org/wiki/Blockchain

https://en.wikipedia.org/wiki/Distributed_ledger


https://bittrex.com/


https://techcrunch.com/2017/04/12/messenger/

http://www.statisticbrain.com/skype-statistics/

http://expandedramblings.com/index.php/twitch-stats/

http://expandedramblings.com/index.php/whatsapp-statistics/

http://expandedramblings.com/index.php/how-many-people-use-chat-apps/

https://ring.cx/en/news#release-of-ring-10-liberte-egalite-fraternite

https://en.wikipedia.org/wiki/BlackBerry_Priv

https://blockchain.info/charts/blocks-size

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf

https://www.quora.com/Why-isnt-the-size-of-the-blockchain-a-serious-problem-for-Bitcoin

http://www.dailystar.co.uk/tech/news/465903/SKYPE-DOWN-popular-messaging-service-offline-across-globe

http://www.dailystar.co.uk/tech/news/465903/SKYPE-DOWN-popular-messaging-service-offline-across-globe

http://www.express.co.uk/life-style/science-technology/800092/WhatsApp-Down-Not-Working-Outage-App-Update

http://www.express.co.uk/life-style/science-technology/800092/WhatsApp-Down-Not-Working-Outage-App-Update

ixian technical white paper · ixian white paper 5 ixian distributed ledger technology ixian...

Documents