CommerceBlock - a public blockchain infrastructure company



  • @commerceblock

    CommerceBlock is a public blockchain infrastructure company that is architecting a platform
    that allows anyone to build and use nancial products and services historically
    reserved for commercial banking customers. The CommerceBlock network will be the
    rst technology platform that provides a combination of trust minimal trade, decentralised
    contract execution, on-chain derivatives, and asset-backed token issuance to public
    blockchains.

    Problem

    The large majority of commerce still relies on traditionally architected nancial products
    and services. These permissioned systems route and account for value in centrally managed
    databases. These custodians and their services are subject to censorship, seizure,
    failure, hacking risk, monopolistic pricing, and other externalities.

    Solution

    The advent of the Bitcoin protocol [2] has enabled permission-less nancial innovation.
    CommerceBlock's product o erings provide a suite of tools that enables anyone to build
    and use services that construct contracts, manage trade
    ows, engage in multiparty dispute
    management, issue assets, and hedge currency risk. Developers and end users will be
    able to manage all stages of a business interaction and ful l their contractual obligations
    by utilising the CommerceBlock platform.


    These services will be integrated into infrastructure we have already implemented. [3]
    We have released the rst open-source implementation of the pay-to-contract and homomorphic
    address protocol outlined by Timo Hanke and Ilja Gerhardt. [4] The protocol
    has been designed in such a way that all business logic, customer funds, and trade details
    are managed on the client side meaning at no point does CommerceBlock have access to
    customer funds or private information.

    Architecture overview


    Building applications that leverage public blockchains must be done with the utmost care.
    There is a long history of poorly formatted transactions, improperly seeded signatures,
    overpaid fees and other such mistakes that have caused irreversible loss of funds. The
    CommerceBlock platform has been designed to abstract away these intricacies to end
    users, while still allowing them to build complex applications.


    The CommerceBlock APIs and SDKs will provide a wide array of functionality to users in
    the form of well-tested libraries and highly available (HA) services. The exposed libraries
    can interact directly with base layer public blockchains, layered protocols such as the
    Lightning Network  and Sidechains  as well as embedded consensus systems. [10]
    Speci cally, the CommerceBlock API will allow users to construct zero-knowledge invoices,
    conduct multiparty escrow , engage in templated in-channel contracts on the
    lightning network  issue assets ,  and utilise other carefully selected advanced
    smart contracting techniques found in peer-reviewed research.

    BIP proposal

    CommerceBlocks rst product o ering is based on our implementation of the pay-tocontract
    protocol described by Gerhardt and Hanke. This protocol is designed to mimic
    real-world payment interactions between merchants and customers. The protocol results
    in only the merchant and customer having cryptographic proof of who is being paid and
    for what.
    We have speci ed and implemented their multiparty key derivation scheme by extending
    BIP-0032 (Hierarchical Deterministic Wallets). We have submitted a draft BIP for
    approval.

    CommerceBlock network actors

    Much of CommerceBlock's tooling will be available for public use on the CommerceBlock
    site. Developers who wish to run our tools on their own hardware can download our open
    source libraries and SDKs. Those who do not want to run their own infrastructure can
    use our paid-access APIs.

    Product Offerings

    CommerceBlock clients

    All of our clients want to trade something. In some cases they want to tokenize the value
    they are trading, in others they require only contractual agreements and escrowed funds.
    We provide the tooling to make trust minimal trading possible in a variety of contexts.
    Below we will describe some of our current clients as well as some use cases we see as
    strong candidates for integration with CommerceBlock.
    Our rst client is building an OTC style marketplace where buyers and sellers of Bitcoin
    can nd each other and engage in a B2B exchange of Bitcoin for direct deposit without
    trusting a third party or being exposed to currency risk. To achieve this goal, the client
    requires two primary tools that we will provide: homomorphic multisig pay-to-contract
    addresses and in-channel Lightning Network derivative contract templates.
    The
    ow is very straightforward: after engaging in a trade, the counterparties must agree
    to the terms of a contract. For example, the contract would specify that the seller is willing
    to part with $10,000USD worth of Bitcoin after proof has been made of direct deposit. In
    this hypothetical scenario, at the time of trade this is worth 2 Bitcoin. A homomorphic
    pay-to-contract multisignature \channeled" address is then derived. This channel will
    have a counterparty taking an opposing bet in a Contract for Di erence, meaning there
    are 4 Bitcoin in total.

    The funds are then deposited into the address by the seller. Once the funds have been
    con rmed, the buyer will proceed to ful ll their contractual obligations. Once proof of
    payment has been made, the in-channel contract will be closed. If the price of Bitcoin
    has fallen to $9,500 the buyer will receive 2.1053 Bitcoin to cover the short.
    The advantages this client sees from using our tooling are three fold. First and foremost,
    they have no custodial risk as the counterparties in the trade manage their own keys.
    This has implications from both regulatory and operational security standpoints. They
    are no longer considered a custodian and they have no hot wallet risk. This saves them an
    e ectively unbounded amount of legal and operational costs. They also can provide their
    customers with trust minimal on chain derivative contracts which is otherwise completely
    unavailable in the market. And nally, the terms of the agreed upon contract are unequivocal.
    No party can claim they did not agree to the terms, making dispute mediation
    more manageable.
    CommerceBlock will provide API endpoints and SDKs to make all of the above possible.
    This is just one extremely simple manifestation of our tooling in production. Arguably
    some of the strongest use cases for our infrastructure will involve Lightning Network based
    exchanges that allow customers to trade derivatives, cryptocurrencies and tokenized assets
    without trusting the exchange to hold their keys. The exchange would manage the order
    book, matching engine and routing without custodial risk.
    Our second active Enterprise Integration partner provides a platform for property owners
    and investors to come together to issue, buy, sell and trade tokenized real estate equity
    and debt. This partner requires our asset issuance functionality. These asset speci c
    marketplaces can be used as a template for other potential clients. We'd ultimately like
    to see all sorts of trading platforms built on top of the CommerceBlock platform. For

    example, other platforms could be constructed that allow for the exchange of digital assets
    (in-game items, gift cards, reward points, etc...) and other natural trading pairs to digital
    bearer assets.
    Finally, our Web UI is perfect for payment redirects and one-o trading between peers.
    Both e-commerce and Craigslist style websites could implement our pay-to-contract invoicing
    directly into their site or they could redirect users to CommerceBlock for invoicing
    and settlement. This would be an alternative to using sites like BitPay.

    Business risks

    A product such as ours poses certain business risks. For example, a traditionally styled
    infrastructure company is a central point of failure; if it is hacked or falters, sensitive
    customer data and business logic can be compromised and critical services can go down.
    Unfortunately, security vulnerabilities and bugs are a reality of software engineering;
    dealing with peoples funds leaves no room for error, so all of our code will be available for
    public peer review, and we will also contract third-party rms to audit it. These e orts,
    combined with the CommerceBlock architecture of client-side fund and data management,
    have mitigated at least some of our infrastructure risk.
    Privacy is also an issue. While payments on most public blockchains lack privacy, we are
    able to mask any business logic or trade details from public view by using our pay-tocontract
    implementation. In the future, we will integrate privacy-enhancing transaction
    protocols into our product o erings.
    Scaling is another common concern when building applications on public blockchains.
    Network costs and wait times for customers using our platform can be variable, depending
    on the available capacity of the public blockchain and the protocols they are using.
    With proper fee estimates, replace by fee functionality, transaction cut-through, Schnorr
    aggregation across inputs, lightning networks, and sidechains, we can suciently manage
    this reality. We understand that the security of a decentralised system requires certain usability
    trade-o s; transaction backlogs and a healthy free market are required to maintain
    the probabilistic security guarantees of the system. [12] We embrace this reality and will
    engineer tools that smoothen the rough edges of these security- rst distributed systems.

    Public blockchains can also experience controversial hard forks, an event wherein a consensus
    code is modi ed in a backwards-incompatible way. This results in the cryptocurrency
    fracturing into multiple coins. In the event of an irreconcilable hard fork, CommerceBlock
    reserves the right to select which networks its infrastructure and development e orts will
    support.
    In comparison, CommerceBlock has a very unique approach. It is well known that proofof-
    work-based blockchain consensus systems have base-layer scaling, security and privacy
    issues. Attempts to enable advanced smart contracting techniques on chains have further
    degraded these already weak areas. There are other strong arguments to be made that
    requiring every full node to execute and validate arbitrarily complex smart contracts is a
    poor design decision. [13] In addition, transactions cannot be made dependent on realworld
    input without having a middleman (oracle) produce the data. This implies that the
    real-world contract logic should exist o -chain, while the actual execution of the funds
    occurs on-chain.
    Our pay-to-contract implementation is the rst step in this direction. Merchants and
    customers can embed their contract into an address, so that the payment itself proves who
    is being paid and for what. The wider network does not know the details of the contract,
    but it is provable in zero knowledge. This is done in a way that looks like a completely
    normal transaction. There is no data bloating the blockchain through OP RETURN or
    bare multisig pubkey stung; if a dispute arises, there will be no question as to what the
    contractual obligations are. While blockchains cannot solve all disagreements that occur
    in meat space, they can certainly make them less ambiguous and easier to mediate. We
    think the distributed ledger and blockchain-based systems that attempt to include all this
    information in the smart contract itself are misguided.

    Our second step towards this end is advanced templating for in-channel lightning network
    smart contracts using discrete log oracles. For example, two parties want to enter a bet on
    the price of Bitcoin (as a hedge); the nature of that bet does not concern the general public
    (including competition). This requirement for privacy would make working on platforms
    that encourage programmatic expressiveness and complexity a competitive risk. These
    parties do not want to associate their funds with a publicly visible smart contract that
    represents a speci c business function, not to mention the fact that the talent pool of
    those who are competent enough to write smart contracts with complex conditional logic,
    game theoretic implications, and non-deterministic code execution pathways is completely
    illiquid. Pursuing such a strategy is not an ecient use of time or money.
    These bettors could instead leverage our contract templates to create a structured derivatives
    bet completely P2P in multisig output scripts. With Schnorr signatures, these
    transactions will be indistinguishable from other transactions with Schnorr signatures
    and MAST would allow for elaborate conditional pathway scripting. The bettors would
    open channels with each other by depositing funds into a multisig address. The channel
    equilibrium would shift when the contract was up and the discreet log oracle blindly signed
    o on the nal price. It would also be possible for one party to novate and atomically
    swap their coins with someone who wished to take over their position without prematurely
    ending the bet. With the modest script tooling available on blockchain systems focused
    on security and code simplicity, you can execute a plethora of excitingly innovative smart
    contracts.
    Our infrastructure will have advantages for asset issuance as well. Currently, issuing
    assets on public blockhains results in a total loss of privacy for asset holders and issuers.
    Whether it is color coins, ERC-20 or a similarly structured asset issuance protocol, tokens
    can easily be tracked by anyone monitoring the blockchain. These protocols also do not

    scale well and create incentive incompatibilities. To address these issues we will utilize
    a privacy preserving solution, to be implemented with closed sealed sets directly on the
    main chain. This protocol will allow assets to be hidden from public view while still
    retaining strong resistance to double spends and attempts at counterfeit.

    CommerceBlock Tokens

    CommerceBlock plans to issue CommerceBlock Tokens (CBTs), a network token that
    will be tracked on a public blockchain. To use services in the CommerceBlock ecosystem,
    customers will have to pay in CBTs. The token will be initially tracked on the Ethereum
    blockchain using an ERC-20 smart contract. When a suciently viable sidechain or colour
    coin scheme is available on a more secure public blockchain, we will transfer the value
    there. We imagine a future in which customers using our infrastructure will also require
    payment in CBT, creating an ecosystem of applications revolving around CommerceBlock.
    The CommerceBlock network token lays the foundation for a public blockchain based
    ecosystem of trading platforms and infrastructure companies. Companies that download
    our SDKs will be fully integrated with CBTs out of the box. By building a self sustaining
    ecosystem of companies that accept CBTs, an emergent network of developers will
    be incentivized to improve upon and help maintain the open source libraries that CommerceBlock
    releases. In this respect, CBTs have a binding e ect: companies that build
    useful infrastructure using the CBTs will increase its value, providing further incentive
    to improve the libraries. This tightly couples the success of ecosystem companies to the
    CommerceBlock network token.

    CommerceBlock ecosystem

    Developers building infrastructure on the CommerceBlock platform will have access to
    API endpoints in our ecosystem that provide the following functionality:


    Token economics


    Token type | ERC-20
    Ticker | CBT
    Total supply | 1,000,000,000 CBT
    Token sale | 40% Token Generating Event
    Payment method | BTC or ETH
    Maximum raise | $25m
    Token allocation
    Token sale | 40%
    Partners | 30%
    Company | 30%

    The token sale will take place on the CommerceBlock token issuance platform. On the
    site, users can make payments in Bitcoin or Ethereum. Once the purchasers payment
    has been con rmed, they will be put in an allocation queue based on the block height
    that their transaction is con rmed in. Each user will be given a unique deposit address
    to ensure miners cannot game transaction-ordering and temporarily censor transactions.
    Tokens will be allocated and distributed asynchronously after being processed through
    the queue.
    A maximum of 40% of tokens will be sold to the public; of that 40%, 20% will be available
    to pre-sale purchasers, which is 8% of the total token sale allocation. If the pre-sale
    allocation is not fully consumed, the extra tokens will roll into the wider token sale. If
    there remain unpurchased tokens from this allocation after the sale has ended, the extra
    tokens will be provably burned. Any over
    ow payments will be refunded.
    A total of 30% of the tokens will be reserved and used as incentives for our Enterprise
    Integration partners. The tokens allocated for Enterprise partners will not be released
    until the CommerceBlock platform is prepared to take CBTs as payment.
    The nal 30% of tokens are allocated to the CommerceBlock company. Of this allocation,
    a maximum of 10% (30m CBT) will be released one month from the token sale closing
    date to cover advisory/token launch costs. The remainder will be locked up for one year
    from the closing date, following which only 20% will be released per year.

    Revenue usage

    Software development | 50%
     Operations | 20%
     Marketing | 15%
     Open-source software development | 15%

    A large majority of our expenses will be used to fund CommerceBlock engineers tasked
    with building the platform. Operational costs will include stipends for consultations
    with legal and regulatory experts, customer relationship management, human resources,
    and related expenditures. Marketing funds will be reserved for large-scale advertising
    campaigns managed by experts.
    A portion of our revenue will be reserved for incentivising engineers to work on the core
    protocols of public blockchains. We will pay developers to contribute to some of the most
    impactful open-source software packages in the space.

    Roadmap

    We will be ramping up very quickly over the coming months. As stated, we have already
    completed an open-source implementation and BIP speci cation of the pay-to-contract
    protocol. We will be using our own Ethereum smart contracts and token distribution web
    interface for our token sale planned for November of this year. Once completed, we will
    be able to provide this infrastructure to our Enterprise Integration partners for use in
    their ICOs.
    Following a successful token sale in November, our immediate priorities will be to hire a
    larger team, research our token strategy, and complete our rst Enterprise Integration.
    This requires us to extend our pay-to-contract implementation to use BIP 148s P2WSH.
    More details about this integration will be announced in the coming months. We will
    have a working private beta for this client by early Q2 2018.
    Our dedicated research teams will establish our token strategy and begin drafting a speci-
    cation for Q1 2018. We will see this infrastructure in beta by Q2 2018. Another team will
    research and implement an alpha design of our templated in-channel Lightning Network
    contracts by Q3 2018.

    Our philosophy is to build tools and rst test them internally and with our Enterprise
    Integration partners. CBTs will be the rst production token on our asset issuance
    platform, and our pay-to-contract APIs and asset issuance platform will be rst tested
    by our Enterprise Integration partners. We will roll out our products to the public when
    they have been thoroughly tested.

    Team

    Having been involved in Bitcoin as early as 2012, the founding team has deep experience in
    the cryptocurrency space. With engineering backgrounds and complementary experience
    in investment and traditional banking as well as technology start-ups, the founders are well
    suited to build out a blockchain-based infrastructure company. The skills of the founding
    team are greatly enhanced by the hand-picked business development and engineering
    teams, many of whom have experience in the cryptocurrency ecosystem.

    Nicholas Gregory, CEO
    Background in technology and nance. Senior roles at Merrill Lynch and JPMorgan.
    Involved in bitcoin since 2012. Working in crypto space since 2015.

    Omar Shibli, CTO
    Technology start-up veteran, having had leadership roles at ZocDoc and Eyeview; opensource
    contributor to crypto projects on GitHub.

    Dan Eve, Operations
    Seasoned business analyst in a FTSE 50 nancial company. Evolved into a cryptocurrency
    advisor, trader, and miner.

    Shachaf Rodberg, Design
    UX/UI designer with years of experience and a passion for cryptocurrencies.

    Valerio Leo, Engineering
    JavaScript expert and smart contract developer.

    Mohamad Shaib, Engineering
    Systems and Infrastructure Engineer, open source and smart contract developer. Passionate
    for cryptocurrency.

    Links:

    Website:https://www.commerceblock.com/

    White paper:https://www.commerceblock.com/...

    Light Paper:https://www.commerceblock.com/...

    Facebook:https://facebook.com/commerceb...

    Github:https://github.com/commerceblo...

    Blog:https://blog.commerceblock.com...

    Reddit:https://reddit.com/r/commerceb...

    Trello:https://trello.com/b/mj708V2E/...

    Telegram:https://t.me/joinchat/Ge36IURX...

    Twitter:https://twitter.com/commercebl...








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