[ICO] Bit Unicom - Connects all devices through blockchain



  • About

    At present there are few Blockchain based dapps for everyday
    use(e.g. Instant Message, Game), most of which implemented or being
    designed are related to digital asset and financial derivatives only.
    BitUnicom is a Blockchain besed development framework
    supports decentralized apps, such as instant messaging(IM), VoIP,
    on-line video, games, distributed computing, machine learning training
    and predicting services, etc.
    All kinds of dapps are built upon shared blockchain as its
    centralized payment and authentication system.
    In the ecosystem, each node is able to get monetary reward
    as resource provider, and consume service from other nodes.
    In such modularized computing model, low-level Blockchains
    like Ethereum or Bitcoin will also play the role of conventional root CA
    and secured DNS for information security.
    The development framework obeys the so-called “public-ledger
    and private data isolation” rule, such that modularized dapps do not
    change the state of Blockchain heavily.
    Communication between peers in such networks are resistant
    to man-in-the-middle attack through end-to-end encryption channel,
    intermediate nodes are not able to monitor or tamper
    information go through them. It’s a completely new secure decentralized
    application network based on PKI derived from public Blockchain.

    BitUnicom Development Framework

    Communication Protocol

    Nodes with static public IP address, which are accessible from any node, can act as
    intermediate application router(AR) or resource hub for dapp transparently. Take Instant
    Message as example, assume dapp node A want to send data to node B. Before initiating
    the connection, A and B will add PK-address of each other to their known contact list, the
    PK-address is derived from the public key of RSA/DSA keystore created for Blockchain
    account. In the simplest way AR publishes its info/status to a public site where dapp can
    fetch directly, and listens on the published port waiting for connection request from nodes.
    Nodes then peek AR directly for connection to target node request. With the help of AR
    node A and B can establish direct encrypted connection by exchanging randomly mapped
    public IP:Port or indirect connection if target IP/Port is blocked by firewall. Multiple sockets
    might be necessary if neither A nor B is attached to public network directly and at least
    one of their gateway does not open port mapping functionality to other device.

    As with direct connection, key exchange and encryption algorithm ECDHE-RSA-AES128-
    GCM-SHA256 is selected to secure the communication between A and B for Perfect
    Forward Secrecy. At the beginning of communication A and B agree upon a shared secret
    key using ECDHE algorithm. It might be unsafe to encrypt data using AES with the secret
    key directly. So the final cipher key for AES encryption is computed from shared secret key
    with a key derivation function. The key derivation function can be negotiated, might be
    MD5, SHA-1 or SHA256. Secp256k1 curve is adopted for ECC. AES is set as the default
    symmetric data encryption. This process of key negotiation mechanism is akin to SSL.

    For undirected connection between A and B, sender first establishes secure channel to AR
    the same way as described above. A sends encrypted data to AR with destination field
    filled as public address of B in the message. If B is off-line, AR can provide extra services,
    caching the message for a period of time with some fee paid. When AR receives
    connection request from B, AR redirects the encrypted messages to B and empties the
    queue. If B moves his credential(keystore file) to other machine and starts the dapps, the
    message can still be received on this new machine. The identity info of nodes can be
    hidden if the data is redirected through AR.

    If B does not find matched source address added previously, the message is discarded to
    resist malicious attack. To block message from any specified address, you need to either
    add it into the blacklist or remove it from dapp thoroughly.

    Both A and B can save each other’s IP:Port to file or database for later connection. If the
    connection fails based on saved endpoint configuration, both of them might need to visit
    AR again to exchange their new mapped public port information.

    On receiving PING message from peer whose address is in ‘friend’ list, the included IP:Port
    mapping for this address is updated, regardless of whether peer’s port or IP has changed.
    So if Both A and B don’t change their IP:Port information simultaneously, the connection still can
    be established successfully, otherwise they need AR’s help.

    Message Format
    Follow is the message format in protobuf:
    message Msg {
    required int32 version = 1;
    required int32 ts = 2;
    required string src_addr = 3;
    required string dst_addr = 4;
    required bytes signed_data_hash = 5;
    required bytes encrypted_data = 6;
    }
    version: version number, default 0x01
    src_addr: source address
    dst_addr: destination address
    ts: the time stamp when message is sent.
    encrypted_data: data encrypted by AES
    signed_data_hash: signature of the hash of original data

    Both the source address and destination address are hashes of account’s public keys
    created on Blockchain account generation.

    Receiver B decrypts the received data with ECDHE derived AES key and computes hash of
    decrypted data, resulting Hc. B then decrypts the signed hash Hd using the public key of
    node A tagged with address source address. If Hc equals to Hd, the authentication
    successes, this message is asserted to be sent from source address; Otherwise it’s
    discarded. The timestamp field and signed data hash are combined together to discard
    duplicate messages.

    For security reason, B can also check if destination address matches value of his own
    public key derived address. Most of current Blockchain implementations support creation
    of multiple accounts. To protect privacy, it is recommended to select address different than
    that of the coinbase(main) account as his communication address.

    With the help of ARs, any pair of nodes can exchange any form of data directly, including
    instant message, file, image and video. Dapps should provide backup functionality for
    users to store the original encrypted app data and the signed hash anywhere they like.
    With signature info, these data can be authenticated and decrypted at a later time for
    legal use. In order to recove the original encrypted data and it’s signed hash, the random
    generated private key of ECDHE for each session must be password protected and saved
    to a safe place.

    Under direct connection, it’s possible to initiates high quality voice and video chatting,
    online games, etc, without Information leakage. For IM, it’s also easy to create group that
    everyone can join.

    Blockchain—Centralized module

    Chris standing up holding his daughter Elva

    The new computing model is built on top of cryptographically protected Blockchain. The
    accounting BUC-token will be issued to pay all kinds of fees. Both AR and application
    developers will be monetarily rewarded with issued tokens. Smart contracts offer the
    ability to transfer cryptographic coins, property and tokens for user automatically. For IM
    AR deploys Network Access Contract into supported Blockchain implementations like
    Ethereum which application node can pay to connect other nodes on the network easily.
    There are many billing mode for AR to control peer connection requests. For example it
    will only accept connections from any node only if the client’s account has enough tokens
    or it’s the first time this user requests establishing connection with others. VoIP
    developers can charge relative low fees based on call time elapsed. They can also add
    ADs into their dapps in form of side banner for extra profit.

    When mining node includes the unconfirmed transaction in a block it generates the associated smart
    contract gets executed. At the time of writing it takes minutes to complete a transaction(with or
    without smart contract code) for most Blockchain implementations, even more than 10
    minutes if the transaction fee is too low. Several confirmations are needed to agree on
    accepting of new block containing new transactions. To achieve better user experience,
    i.e. for two nodes to establish connection on the fly, post-paid accounting mode is a good
    choice for real-time applications. For example, AR will allow incoming connections
    immediately if requester has enough token balance(reading account state from Blockchain
    is very fast), the charge transaction is executed after successful connection.
    In Ethereum the JSON-RPC interface is open to communicate with Geth. The Geth JSONRPC
    listens on port 8545 by default. If Geth is started with --rpcaddr IP option, the JSONRPC
    can be called from any computer that is able to establish connection with endpoint
    IP:8545. For example if the IP specified is computer’s network ip address and a port

    mapping for IP:8545 is added to the router’s forward table, anyone in the Internet is able
    to call the JSON-RPC service. Once the ethereum account is unlocked and some transfer
    transaction is completed, other machine may get control of your account by sending Geth
    JSON-RPC command, the user is at the risk of losing his money. So for security reason the
    RPC should be configured accessible from local machine only, except you have special
    requirement. To achieve this enable Geth JSON-RPC api either with --rpcaddr 127.0.0.1
    option or just do not pass --rpcaddr parameter.

    All messages transmitted between peers running dapps in this network are hashed and
    signed by user-created private key of RSA or DSA, which can only be authenticated by
    public key queried from the Blockchain once the sender has finished transactions. If the
    authentication fails, the information is asserted not to be sent from a trusted user who has
    registered and make transactions in Blockchain. Historical message record signed with
    private key can be taken as true evidence if necessary, because it’s impossible for user to
    forge signature of incoming message himself.

    An blockchain abstract layer between Ethereum and dapps/ARs will be built to ease
    implementation of in-app payment. Besides Ethereum, This layer may be implemented to
    support more than one Blockchain such as Bitcoin in the future.

    Dapp Data

    We obey the “isolation of public-ledger and private-data” design rule to avoid repetitive
    Blockchains development and unlimited block size increasing. Blockchain will always store
    only transaction records and smart contracts. It’s up to application itself how data are
    processed and where to store outside the Blockchain. Dapp can keep data for any long
    time, depends on the user request. For simple end-to-end application, it suffices to store
    data in files or lite databases. There have been comprehensive solutions being developed
    for decentralized storage that is scalable and reliable for so called Web3 application, most
    of them use Merkle dag to organize objects for efficient storage and retrieval. Take IPFS
    and Swarm as example, both of them are declared to be low-latency, fault-tolerant, zerodowntime,
    utilizing block storage model where large files are chopped into pieces that can
    be processed in parallel. Swarm is deeply integrated with Ethereum Blockchain. Storing
    dapp data independently alleviates network congestion, there is no need for unrelated
    users to download the data.
    Dapps can read account state(such as user’s token balance) and change the state of
    Blockchain through blockchain abstract layer between dapp and Blockchain. The security
    of application data transmitted in network except that stored in Blockchain directly is
    guaranteed by the PKI adopted in Blockchain. Application Routers or other peers cannot
    intercept and forge message because lacking other node’s private key.

    Discovery of AR and peer nodes

    AR nodes act as the role of conventional Internet Server with a public IP address which
    can be queried from DNS server. Instead of accessing AR through traditional DNS query
    which might not be reliable, BU adopts blockchain based solution. AR registers its identity
    information (name in the blockchain network domain, blockchain account address, derived
    from public key using some hash function) and IP address into a DNS Blockchain with small
    amount of fees, such as namecoin or a smart contract built on Ethereum providing domain
    name service that binding registrant’s IP address. Name holders(the person take over AR)
    may want to renew its name information on Blockchain on expiration or its IP changes.
    The valid period of names depends on the registration fee paid, the more paid the longer
    time the name stays valid. Peer nodes running dapps are able to query AR’s IP address
    from the independent and secure DNS supported Blockchain free of charge. It’s resistant
    to attacks like DNS-spoofing. Once the name owner finished Blockchain transactions for
    the name, his public key can be queried by everyone. The DNS query result can be
    verified with name owner’s public key recorded. Poisoned IP won’t pass verification check
    unless the private key is comprised.
    It’s also feasible for AR operators to publish their information (Blockchain account address,
    IP address, availability status) where other nodes are able to access timely.
    It’s designed several steady root ARs to be always on-line on the global, which are also
    called bootstrap ARs. Other general ARs’ information can be retrieved from bootstrap ARs
    quickly. Bootstrap ARs peek each other periodically, 30 minutes for example, to
    exchange and update the information about general ARs.
    In extreme cases a dapp might fail to find target peer node through ARs, all of the ARs
    might be down or blocked. We’ll extend the Kademlia DHT(distributed hash table) as
    auxiliary tool for efficient search of target node for different dapps and services in BU
    network. Under the XOR distance metric, the node ID containing longest common prefix
    with target node is closest. Every dapp in this framework is assigned a unique application
    ID on registration. Each entry in the hash table’s bucket consists of (node ID, list of
    <public IP:Port, application_ID, agent, ...> tuple). Because each node may run more than
    one dapps based on the same framework, the application_ID info is added into the entry
    of DHT. Each time a new dapp entered the network, all of the DHT’s entry containing this
    node will be populated to include the new application ID and IP:Port info. Port is added
    because different dapps running on same node must occupy different mapped public
    ports. Other descriptive information can also be added, e.g. dapp’s agent name.
    On joining the network, the new node publishes it self(address, <IP:Port, application_ID,
    agent, ...>) to the network(through preconfigured bootstrap nodes). The new node puts
    bootstrap node into its DHT buckets and initiates searching itself against the bootstrap
    node. Searching itself will populate other’s hash table with this new node’s information,
    such that other nodes can find the new node by searching address and application_ID in
    the network DHT.
    UDP packet is used to transmit the node information for extend DHT node discovery. All
    packets exchanged are signed with private key which can be verified directly by the public
    key retrieved from Blockchain to resist malicious attack.

    Unified Account

    With Blockchain as the centralized security and payment architecture, there is no need to
    create separate account for each dapp in this computing model. Different dapps share a
    common account by importing the private key and public key from the keystore user
    created for Blockchain at start time. For security reason the keystore should be encrypted
    by AES with key calculated from PBKDF(Password-Based Key Derivation Function, e.g.
    pbkdf2, bcrypt and scrypt).
    AES_key = hash(pbkdf(password, params...))

    Each time the dapp starts up, the user has to input password to unlock the password
    protected keystore.
    To resist malicious attack, all the messages are required to be signed with sender’s private
    key. If the public key included in the signature can not be found in blockchain or the public
    key derived address does not match the source address of the message, the message
    should be rejected. So in order to participate in the BU network activity, the user must
    have finished transaction(s) in the blockchain. Allowing only those have sent transfer
    transaction(s) to use dapps into the BU computing network strengthens the security of
    system, alleviating abuse of account to some degree.

    more applications

    Web service

    A public-IP Node can register itself in DNS Blockchain and run web server, with all
    information secured by cryptographic algorithm based on built-in PKI in Blockchain.
    Blockchain provides encrypted dns and Certificate Authority services directly. Only sites
    whose certificate verifiable rooting from Blockchain as the endpoint are trustworthy.
    It’s easy to implement a decentralized web server with resources locating on different peer
    nodes. It may caches visited resource. It can also redirect visit requests to other nodes
    and return the results to visitor. To encourage nodes participating in data sharing, nodes
    get reward each time providing resource(pages, images, videos) to visitor. The reward
    usually comes from fees paid by advertisers.

    Cloud Computing and Storage service

    It’s easier for peers to find available resources on decentralized network through nodes
    called Application Server. Take distributed computing as example, distributed computing
    organizer collects redundant computing resources over the network, and rents them to
    enterprises, government departments or scientific group for research.
    The SP(may be any node over the network) can rent idle resource of different types to
    different clients. It can register its CPU time to computing ARs and free disk space to
    storage ARs separately.
    The CSP provides services by executing received tasks or subtasks from AS. CSP’s
    computing engine dispatches these tasks to different containers after receiving paid
    tokens, and waits for execution to complete. The computation result is returned to
    Application Server. There may be more than one container hosted on same machine.
    Container is chosen to run more processes efficiently with less resource than VM. It
    presents clear boundary between tasks and efficient way to isolate different processes.

    For each computation task defined by developer or costumer, a DAG for data flow is
    constructed, and optimized if possible. The DAG topology is built on a single node. It
    represents the data processing pipeline, which is run using data execution engine. For
    simple tasks, the pipeline is just a sequence of single-input-single-output primitive
    operations. For complex tasks, these operations forms a graph where there are multiple
    input sources for a operation. The stream execution engine processing stream-like data
    will be developed to process unlimited data set. The user do not need to interact with
    stream execution engine directly, it’s encapsulated together with DAG constructor.

    In most cases the data processing time is usually behind data producing time for all kinds
    of reasons. Assume the data set producing time series is T0 < T1 < … < Tn. It’s possible
    that data produced at Tm arrives after the data produced at Tn, where m < n. After Tn is
    processed, the results are partially correct. Such kind of problem caused by time
    difference is called deviation. To eliminate this problem, when old data is observed the
    previous process results are improved. Correcting the results on “new” data(this data
    might be produced very early) arrival makes results more correct than as ever processed
    before. When all of the data is observed, the deviation is eliminated completely. It’s a
    iterative optimization and correction process to update the result of your computation on
    new data arrival.
    Customer will be provided abstract Task Define Language framework. The task language is
    processed by pipeline DAG constructor on computing server.
    The optimization steps are executed by the framework automatically. Developers are
    released to pay more attention to the application logic itself.
    Another important part of the framework is resource allocation engine. The computations
    in DAG pipeline may be executed across multiple machines. Application Server
    dispatches data to different nodes which have the structure of optimized DAG for
    processing in parallel. AS selects nodes based on their historical credits. It’s likely that
    nodes with higher credits will complete desired computation, have higher chance to be
    assigned tasks.
    For data storage if size of the file to be stored exceeds some threshold(say 4MB), client
    splits it’s file into small pieces and encrypts them, then builds Merkle DAG based on these
    blocks. Each block contains the info about storage AS. These blocks can be addressable
    by searching extended Kademlia DHT their content hashes. The Merkle DAG’s root node is
    sent to storage AS which has collect enough free disk space from SSP for future verification
    on client request. For file blocks to be stored as long as possible, a majority of the service
    fee can be paid to SSP at file recovering time. Nodes will be paid more fees if they can
    recover the whole file at a later time. It’s possible for SSP to move the encrypted file
    block to others through Ethereum’s temporary ownership transferring contract. After new
    node receives the file piece through ownership transfer contract, it sends the block’s hash
    and hosting info to the storage AS. AS can also provide visualization services to customers
    for monitoring file status.
    In both cases service provider gets paid by percentage of workload finished. For storage
    service the work is usually measured by space and time used. For computing service it is
    measured by the data processed.

    sa

    cloud computing in BU network
    Each block’s Dag Node is designed to contain the owner node’s signature, which contains
    object owner’s public key. Only the block owner can modify and publish the changes to it.
    Block change are signed by publisher’s private key and broadcast to network. On receiving the


    change, the node verifies the signature with block’s public key. The change is applied if
    signature is verified, otherwise rejected.

    Artificial Intelligence service

    Huge computing power is consumed for hash computing as proof of work, which is kind of
    wasteful in a sense. Many cryptographic coins mining ware runs on GPU, which is also
    good at solving machine learning problems. So these miners are encouraged to rent their
    GPU power for solve AI problems, both training and predicting. With trained model they
    can provide prediction service multiple times to clients, such as advertisement, helthcare
    and financial industry.
    The opensource deep learning tool Tensorflow has built-in support for distributed training.
    It will be adopted as the default tool to providing AI services.

    Other applications

    In many industrial fields, traceability is very important. In many cases we need to verify
    history information, such as food process, supply chain, health care. All subsequent event
    info record contains hash link to previous history record. Existing Blockchain can be
    extended to include signed hash of dapp data into transaction record within each block for
    later verification, avoid putting big data blocks into the Blockchain.

    All distributed resources treated as files

    Similar to Linux, including CPU and memory, all resources in the system are treated as
    block file, which provides a set of unified query interfaces to user. The owner node
    publishes block’s info into DHT for query and swap on startup. Customer rents or obtains
    available resource registered on centralized/public nodes. User defines task containing
    sender’s info and sends it to block(device) which is capable of performing the task, either
    through the centralized node’s execution engine or to the block itself directly. The
    execution result is sent back to requestor asynchronously.
    Large file blocks are split into small pieces, and a Merkle DAG is built. Restoring process
    starts by downloading current node’s data and the data its links pointing to recursively,
    starting from DAG’s root hash. Integral file block can be retrieved by search DHT only the
    Merkle DAG’s root content hash as key in the network. So if the root hash is lost, you are
    not able to restore the file. Storing small pieces of large block on different nodes is very
    important for parallel download, such as for video service provider.

    Incentive for Node to work as Application Router

    In normal P2P networks, it takes relative long time to locate peers for end-to-end
    connection without the help of stable centralized nodes. In the designed BU network
    nodes running AR server gets monetary reward by providing a bridge for different dapps.
    It can either work as resource scheduler or provide storage or computing service for
    clients. All the data passed through or stored temporarily by AR is secured, only receiver
    can decrypt it. AR can also push Ads to client on connection request to provide long-term
    and steady service.

    Market

    With the development of P2P payment market and Blockchain, fully private P2P IM
    providing end-to-end encryption will get more attentions than ever. End-to-end IM helps
    establishing real-time connection, payment, money transfer, e-commerce, VoIP, etc. For
    those take part deeply in cryptographic currency and need high-level security encrypted
    end-to-end P2P IM is a ideal choice.
    The enormous demand for cloud computing both in industries and scientific communities
    is attracting more dapp developers. It’s very common for artificial intelligence algorithms
    like deep neural network, LSTM to take days or even weeks to training a high-accuracy
    model. Hyperparameter optimization is also a very heavy task, which can be executed
    fully in parallel. So it’s a big chance for miners who own thousands of GPUs suitable for AI
    tasks to participate in the ecosystem, including AI model training for enterprises.
    Incorporating public application routers and resource dispatcher and process with
    Blockchain network make real-time decentralized computing easier.

    Developers

    We’ll build a set of highly reusable componenets for developers to quickly build dapps
    enabling pair of peers establishing end-to-end encrypted communication for any kind of
    Internet application or providing cloud services, account module, AR, off-Blockchain
    decentralized files system or database. We’ll also provide a Blockchain abstract
    transaction library, allowing developers to pay more attention to their business logic.

     BUC token

    BitUnicom token is the important element of central payment system for dapps, service
    providers and network operators. It’s used to pay for real-time network access, cloud storage,
    data exchange, ai services, and so on. BUC token will be issued during crowdsale period. The
    total supply of BUC token is fixed.
    The BU tokens to be issued will be used to pay for access of computing resources and services
    available in the network.

    ICO in Progress

    BitUnicom

    Protocol:  ERC20

    preICO duration(UTC):  Oct 25, 2017 00:00:00 - Nov 05, 2017 00:00:00

    How To Participate?

    PreICO/ICO is based on Ethereum, accepting ETHs.   During the PreICO/ICO stage, BUC tokens will be issued and sent to investors on receiving ETHs.  

    Contract address: will be published immediately before preICO start,    send ETH to this address to get BUC tokens

    1) If you have a ERC20 compatible wallet, like EthereumWallet, MyEtherWallet, simply transfer ETH to the ICO smart contract address, you will receive BUC tokens equivalent to ETHs transferred.

     2) If you do not have a ERC20 compatible wallet, create a wallet from https://www.myetherwallet.com/, buy ETH from available cryptocurrency exchange, then withdraw the ETH into your Ethereum wallet just created. At last transfer ETH in your wallet to the ICO smart contract address to receive equivalent BUC tokens.

    Bonus for PreICO:  35%


    **Important Note**: Please do NOT send ETH from any exchange, otherwise you will not get BUC tokens!!!


    ROADMAP

    Q2-Q3 2017

    Project Launch Blockchain and Cryptographic Analysis Writing Smart Contract White Paper Publish

    Q4 2017

    Communication Protocol Refinement Extended DHT Routing Network Draft Dapp Node Discovery Protocol Release

    Q1 2018

    Abstract Layer between different Blockchains and Dapps IM Prototype Publish

    Q2 2018

    Blockchain Account Integration Communication Channel Key Exchange Protocol Voice over IP Functionality IM Test release Extended DHT function for different dapps on same node Test

    Q3 2018

    IM Alpha Release Dapp Data Backup and Restore Function for History Information Proof Application Router Alpha Release Bitunicom development platform release

    Q4 2018

    IM Beta Release Distributed Computing Framework Publish DataFlow Graph Execution Engine

    Q1 2019

    Application Router&Server Refinement Distributed Computing Platform Test & Publish

    Q2 2019

    Distributed Computing Platform Alpha Release Establish Net of Intelligence distributed globally

    Q3 2019

    Distributed Computing Platform Beta Release

    Links:

    Website:

    White Paper:

    Facebook:

    Twitter:

    Youtube:

    Stackexchnage:

    Slack:



Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.