Syscoin: A Peer-to-Peer Electronic Cash System with Blockchain-Based Services for E-Business Jagdeep Sidhu, Msc. Syscoin Core Developer Blockchain Foundry Inc. Email: http://www.blockchainfoundry.co/contact-us Abstract—While Bitcoin (Peer-to-Peer Electronic Cash) [Nak] applications. This is in contrast to using turing-complete solved the double spend problem and provided work with smart contracts, which, by definition, are not hardened due timestamps on a public ledger, it has not to date extended to the open-ended nature of the underlying scripting lan- the functionality of a blockchain beyond a transparent and guage. Commercial integrators who are looking for a secure public payment system. Satoshi Nakamoto’s original reference solution to leverage the increased efficiency that blockchain client had a decentralized marketplace service which was later technology allows compared with traditional e-commerce taken out due to a lack of resources [Deva]. We continued with applications are better off trying to use a hardened service Nakamoto’s vision by creating a set of commercial-grade ser- which cannot change and is well-tested with regression vices supporting a wide variety of business use-cases, including testing, white-box and black box testing, specifically tar- a fully-developed blockchain-based decentralized marketplace, geting rules of the application. Integrators are also inclined secure data storage and transfer, and unique user aliases that to choose the most powerful network available which is link the owner to all services controlled by that alias. currently Bitcoin, so the optimal solution for them would be to have a hardened contract which does what they need running in an environment which is protected by Bitcoin’s 1. Introduction network security; these requirements make Syscoin the most viable choice. Syscoin is a permissionless blockchain-based cryptocur- rency with a set of smart contracts which have been thor- 1.1. Turing-complete scripting oughly tested and built on the Bitcoin scripting system using OP1 to OP16 standard script op-codes, representing Turing-complete smart-contracts are technical marvels. coloured coin transactions, controlled by a hardened layer of But one has to question what real use they can be to practical distributed consensus logic for each smart contract (Syscoin business processes. For general purposes business logic is service) while still retaining backwards compatibility with hardened upon the Software Requirements and Specification the Bitcoin protocol. These contracts can be combined and stage of the software development life-cycle. It makes sense made to communicate with each other, forming building to harden the rules of the contract, running on a system blocks for blockchain-based e-commerce solutions. For ex- that has a measurable number of points of failure as does ample, the Syscoin Alias Identity service is used by all Bitcoin. With the mix of variables at the intersection of de- other services to create cryptographic proof verifying the centralized networking and Turing-complete smart contracts ownership of an Identity and ensuring that the owner of compounded by the complete lack of development oversight an Identity is the only one who can make Service related and vetting that Ethereum applies to contracts deployed to its agreements, update offers and create or modify certificates. network creates the potential for disaster scenarios for those The Identity service also allows the owner of an Iden- invested in/using these smart contracts as was proven by tity to communicate encrypted messages to other Syscoin the DAO experiment [But]. Here we had a malfunctioning Alias Identities. Impersonation is avoided by including the code-path that was discovered and leaked a large sum of Unsigned Transaction Output (UTXO) of a previous Alias money rendering the experiment as a failure. It revealed transaction that then belongs to the user owning the Iden- larger issues with the design and immaturity of Solidity tity and including it in future service-related transactions. [Dai], the official language used to write smart contracts Typically when creating a Syscoin service users have the on Ethereum. With Turing-completeness comes an infinite option to specify which Identity the service belongs to. Most paths of execution and risk of failure. We can make the of the major use-cases using smart contracts with online guess that it is an evolutionary process of finding issues, one services would use a subset of these services; it makes sense can equate the DAO attack to SQL injections which caused to harden these smart contracts and introduce them as a pain to many data driven web applications in the late 90s. commercial-level quality set of tools, used by developers Had Solidity been written so it made it harder to write bad and integrators to create tomorrow’s disruptive blockchain contracts perhaps the problem would have been prevented.
The consensus currently is that if you do not need smart 1.3. Syscoin as a currency contracts to solve your problem it is best avoided until the languages and toolboxes on top of the smart contract core Similarily to Bitcoin, Syscoin acts as a payment sys- API are hardened to a point where they certified to be used tem whereby tokens can be securely transferred within the by the general public. It is an open-box software experiment Syscoin network. Syscoin tokens currently have an active that is useful for applications which can offer cost-effective market and an observable value, as such they have begun contracts that must change on demand. In the context of to fulfil the basic functions of a network currency in terms most of the e-commerce applications we have seen, this of acting as a store of value, a medium of exchange and a level of flexibility is not required. In contrast, with Syscoin unit of account. As the network scales up, and as the tools we have decided to try to generalize applications into a we have developed are used by increasing numbers of users, set of hardened services that can be used in conjunction Syscoin tokens will continue to function as the main token with each other to create complex use-cases, some of which powering the network. are visionary and some of which are disruptive to current business flows without totally re-designing them. In an effort 1.4. Design philosophy to introduce such technology to the real world, which has employed certain processes for years, it is important to try Syscoin was developed in a carefully designed Agile to introduce new technology in a way that is adaptable to development process with compatibility with parent source the existing processes and works within existing judicial and code network Bitcoin in mind. Since Syscoin was forked legislative frameworks. In the grand scheme of things, the from the Bitcoin codebase it makes sense to leverage the speed at which a smart contract can be developed does not community of that network in terms of mining and devel- matter if it has a high risk of being effectively insecure. opment by ensuring it is as easy as possible to rebase Bitcoin into Syscoin upon major code releases. Merged-mining with Bitcoin means Syscoin users can enjoy a powerful network preventing double spends and other network related attacks. 1.2. Innovative service layer At the time of this writing the Syscoin network carries about 25 percent of the mining power of Bitcoin [Cry]. The goal was to innovate on top of Bitcoin source code- We have created an effective Alias Identity system which base but be backwards compatible to leverage the network allows payments, to and from, direct towards recognizable effect of Bitcoin in a manageable way. Since Syscoin is names. Identity systems have associated data and pub- fully complaint with Bitcoin, all of the external tools and lic keys internally stored, making them useful to perform processes meant for Bitcoin can also work with Syscoin. blockchain activities such multisignature signing, payment The key difference at the core level between Bitcoin and discovery and maintaining identity payment balances. We Syscoin is that Syscoin can handle 1 minute block times took an intuitive step forward from the Bitcoin core code- for faster settlement of transactions. Although Bitcoin was base and extended it with capabilities that made business not designed to be a transaction processing mechanism and sense without sacrificing security. network speeds have demonstrated to be increasing by at An alias can then create an offer in the decentralized least 50 percent per year based on Neilsen’s Law of Internet marketplace to exchange goods without alias owners. Note Bandwith [Nie] (Neilsen accurately predicted that the 300 that the alias is cryptographically linked to a service such bps modem speed in 1984 would increase to 120 Mbps as an offer by enforcing a rule that the alias output of lines in 2014) we can safely assume that majority of the the last alias transaction is linked to the creation of any network around the world will be able to settle transactions subsequent Syscoin service transactions. This ensures the within 1 minute rather than a 10 minute window. Syscoin owner of the alias identity is the only person who can make supports 1 Mb blocks, resulting in the ability to process those transactions. Offers and certificates may work together 10 times more data than Bitcoin. This was needed because in the sale of digital goods. the average transaction size in bytes for Syscoin service A certificate is a proof of ownership token of data that transactions range from 2 times up to 10 times the size can have arbitrary public and private encrypted information. of an average Bitcoin transaction. Even so, the pruning It is transferable and generally done so at request or upon mechanism that was innovated by the Syscoin engineering a sale. team is able to cope with demand for Syscoin service related data by removing the bandwidth and storage constraints Escrow is used to facilitate the exchange of goods or on the network for service data for these transactions after services and money. A general purpose escrow service was service expiration. incorporated into Syscoin by allowing for transactions to be At the time of this writing, the Bitcoin codebase is created at each step; from the creation of the multisignature about 114k lines of code (physical SLOC). Syscoin’s code payment, to the payment or refunding of that payment. (around 19k lines of code) on top is about 16 percent Messages can securely transmit communication between of Bitcoin’s. An external library cryptopp was added for alias identities to facilitate trade negotiations or requests encryption mechanisms used for certificate, private alias and amongst participants in Syscoin service usage. offer buyer note fields which added 25k lines of code. In
total there is about 158k lines of code to date. It is important either Bitcoin or Syscoin by using the desired version byte that code coverage through unit tests correctly indicates prefixed along with the Hash160 of the Syscoin public the health of the underlying code base to ensure that any key. In ZCash’s implementation, 2 bytes are prefixed to changes made do not have unforeseen ripple effects. Not the Hash160 of the Syscoin public key (”t1” and ”t3” one individual or team is aware enough intellectually to be addresses). This way, at the network level, Syscoin is able to able to accurately determine the state of health of a system respond to requests for payments in other chains and collect across every isolated change. Since a system like Syscoin those payments all from within one merchant key (the Alias relies on valuable tokens which power the network and store Identity associated with the merchant). An interface within users’ wealth, it is imperative that the code supporting those the wallet for Syscoin has been built to manage usability tokens is in a state that is safe for the general public to of these payments by connecting to these other chains use. Diligence is mandatory for any responsible actors in via RPC connections to validate payments to merchants the development sphere to ensure that any code intended to for offers. The validating nodes could be standard nodes be used by people who do not understand the open source for ZCash and Bitcoin running txindex=1 to ensure cross- protocol or who cannot read code is safe to use. Bitcoin network transactions can be queried by the getrawtransac- developers do a good job with covering their code through tion RPC call. A sendrawtransaction RPC call happens upon unit tests and we have developed a test suite for testing an escrow completion related to a Bitcoin or ZCash payment Syscoin services by running multiple nodes while running for an offer. All escrow-related cryptographic signatures tests (black box testing). The number of tests in Syscoin is can happen within Syscoin because of the compliance of 137 while Bitcoin has 136. The number of tests per line of the address schemes between Syscoin and these supported code is sufficient to prove that the quality of work done in external chains. This greatly improves usability for escrow- Syscoin matches or exceeds Bitcoin’s code base. related payments by hiding the complexity of a multisig- nature process of an external chain payment within the 1.5. Alias identities as the backbone of Syscoin Syscoin escrow core service code. The only dependence lies in the face of the user interface which is mere convenience. services Payment validation at the network level allows cross-chain payments to be validated just as a native Syscoin payment Part of what makes the services in Syscoin so intriguing by validating that the destination address and amounts are is the connection they have to an alias identity system. correct for the offer being paid for. Any interface integrating Offers, certificates, messages and escrow all require actors with the Syscoin core can use their own method for vali- to sign off on creation or updates of these services via dating that these external payments exist on their chains in their aliases. Cryptographically secure signatures (backed the correct amounts; wallet-less nodes with txindex flag for by enormous proofs-of-work) are required in order to make each chain which can be accessed by the interface will be changes to the services that aliases are linked with. By sufficient in most cases. linking services to an identity system it makes it much easier to integrate services into real-world scenarios which 1.6.1. Mechanism design. Bitcoin provides two incentives work with identity-based work flows. Almost anything we for miners: block subsidy through rewards and transaction do today requires the signature of a known actor on the fees. As Bitcoin rewards wind down it will become un- service contract. By providing a cryptographically secure stable due to degrading miner incentive to do what’s in mechanism to create, manage and link these identities to the best interest for network security. Selfish-mining and service contracts, it ensures a seamless integration to pro- undercutting are very real problems in Bitcoin’s mining cesses in real-world scenarios. Not only does this make world. These are discussed in greater length in this paper it easier to understand and explain to others how to use presented at the ACM CCS [Nar16]. What we present is Syscoin’s services, but it is also easier to implement more a novel mechanism design that prevents mining incentive dynamic features on top which leverage the use of aliases, from degrading by tying in usage of services to an in- such adding multisignature options to aliases to improve the flation metric for block rewards. Transaction fees remain workflow of common contracts where multiple parties rep- to provide incentive to mine and relay transactions but resenting a single identity are required to sign. Partnerships, rewards will continue depending on the demand for using common law or power of attorney contracts are examples the Syscoin network. A utility metric can be established of such cases where multiple signatures may be needed to by determining the number of Syscoin service transactions represent an identity. per block. In Syscoin 2.1, an arbitrary number was chosen (5, not network enforceable) which represents the ”high- 1.6. One key to rule them all demand” cutoff threshold for when to burn fees (under the threshold) or when to inflate the fees in the rewards Because Syscoin private keys are equivalent to Bit- (above the threshold). This means the monetary base can coin and ZCash Transparent keys, these chains along with expand (inflate) however so slightly to accommodate for Syscoin become tightly coupled in integration for mer- the demand to use Syscoin services and contract (deflate) chant payments on the decentralized marketplace. Syscoin when there are blocks that fall under the threshold. It is merchants can provide their merchant payment address in important to note that the fees in question that are being
burned or inflated are not the transaction fees, which are stored and dynamically adjustable during network run-time always paid to miners separately from the block reward, but to avoid having to do any soft or hard forks and having them the Syscoin service fee, which is on top of the transaction take affect in real-time versus voluntary updates of miners fee and is a dynamically adjustable fee from within the rates and client wallets. Transaction fees are used for determining peg aliases. This creates a democratic system that carries the the amount of fees used when sending payments to escrow fee rate which is capable of adjusting the monetary supply with Syscoin, Bitcoin or ZCash [Devb]. Because miners may based on demand or lack thereof during block producing change the amount of fee it takes to mine and relay a trans- events by miners. The result is a price stability mechanism action, these variables are best to be dynamically adjustable similar to inflation targeting by central banks but is done based on market conditions. Of course, sysrates.peg is just a in a decentralized fashion. High demand for the tokens will reference implementation of such an exchange rate service correlate with a slight adjustment to the supply positively to bootstrap the marketplace with a ready-made and updated while low demand will deflate and give current token holders alias with exchange rate information. It may fulfill the needs more stake as a percentage of total supply (similar to the of 90 percent of users who do not want to manage their own Proof of Stake consensus algorithm, but in the context of a exchange rates and fees. However, for the select few who Proof of Work architecture). The mechanism design closely do care, they may change the alias that their offers use for follows the concept of Ideal Money [Nas02] termed at a exchange rate information and even expand the exchange- Penn State lecture given by the late John F. Nash Jr. (Nobel able currencies they accept. Their peg may also be used Laureate in Economics). If we apply the notion of service by others who feel perhaps that sysrates.peg fees are not transaction rate to facilitate the transfer of utility between desirable and want to use a different option (anyone can network participants we have a metric that is the first of create their own exchange rate peg). By allowing users to its kind, one that denotes true demand for the currency in select the exchange rate alias that their offers relies on, it circulation as a public utility that is audit-able and provides creates a self-governing system of exchange rates and fees money transfers with transferable utility, and thus, ”quality” which adapt to the needs of the users on the network. See money which would classify as ideal. Nash alluded to using below in the Alias Rate Peg section for how the pegs can a ”public utility” such as the supply of electric energy or create a democratic rate system which scales with the price water as a high quality utility for inflation targeting but those of Syscoin. are indirectly related to demand which is indirectly related to velocity of money. A utility metric would be ideal if 1.6.3. Quality assurance through network simulation. when detecting real velocity of money that the quality of A test suite was developed to allow the simulation of live utility is maximized which divides over M1 (money supply). network scenarios. Tests cover pruning, expiry and general Traditional money velocity is calculated using GDP over use-cases of Syscoin services. It is an integral part of M1 or M2 however GDP is a lower quality utility metric achieving a commercial quality level product in any software used which is not publicly audit-able due to a wide range application. The setmocktime rpc call is used to set the time of factors influencing the utility and susceptible to a range in-advance of blocks to simulate expiration of services and of public perceptions based on how it is calculated. See pruning. shadowstats [Wil]. Syscoin provides a way to determine the highest quality utility metric possible by providing a way 1.7. Alias identities to calculate true money velocity directly by averaging the service transaction creation rate over the monetary base and We have applied domain-name like rules to Syscoin adjusting the base to accommodate demand to achieve price Alias Identities, allowing only unique case-insensitive stability. names. We have changed the Alias renewal model to be The threshold can be extended to become dynamically more like Internet domain names; Aliases can be renewed adjustable through the peg rates alias but this was intention- up to five years at any time. Users are now able to send ally left to a static number to keep the mechanism simple coins and encrypted messages to an Alias using any case and allow public auditability and perception to not become formatting desired, the recipient will always be the same. erratic. This would affect price stability as it would begin to For example, using ”Dan” or ”dan” is equivalent and will obfuscate what the true utility value is at any given moment. go to the same recipient the user who owns the lowercase version of the Alias ”dan”. 1.6.2. Self-governing rate system. Because we wanted The following domain-name rules apply to Aliases upon users to be able to transact in currencies other than Syscoin, creation: we needed a way to access this information not only in the • The domain name should be a-z/0-9 and hyphen(-) user interface but in the consensus code to be able to validate • The domain name should be between 3 and 64 that offers were paid in correct amounts and to the correct characters long person. • Last TLD can be 2 to a maximum of 6 characters To do this we created the sysrates.peg alias which stores • The domain name should not start or end with currency information in relation to Syscoin price. It is hyphen (-) (e.g. -syscoin.org or syscoin-.org) updated dynamically based on the volatility on exchanges. • The domain name can be a subdomain (e.g. Other things such as transaction fees and arbiter fees are also sys.blogspot.com)
• The pricing model depends upon the length of re- 1.7.5. Alias balances. Since payments to aliases send newal, it is the product of the normal Syscoin service change back to the alias address it becomes a natural evolu- fee with the square of the renewal length. tion to keep alias balances. The UTXO related transactions • F = F * pow(2.88, R) where F=fee in coin amounts for each alias are kept in a separate database to allow and R=renewal from 1 to any number (years) spending to and from aliases distinctly separate from other outputs that are available in the wallet. It allows for clean 1.7.1. Cryptographic security through alias identities. management of funds as well as provides simplicity when Any Syscoin service you create or update must update an dealing with multisignature funds which need signing from Alias identity input which employs a cryptographic scheme multiple parties for spending. It also allows for interaction that secures the transaction with provable ownership of those with the Syscoin services through utilizing the alias authen- transactions. Consensus code for Aliases, Offers, Certifi- tication mechanism which provides the private key for the cates, Escrows and Messages all require inputs from the alias to unlock UTXOs related to that alias for updating, Unsigned Transaction Outputs(UTXO) of an Alias Identity adding or removing services related to that alias, all in a transaction that has been signed with the owners private key. headless state without the need for wallet interaction. The This allows for an Identity to play a key role in ensuring alias acts as a keystore then and becomes your wallet for safety, secure from impersonation or any other attempt at at- the funds inside that alias. Your alias password can be used tacking the integrity of the relationship between the Identity to unlock those funds using any tool capable of sending rpc and services that are involved with the Identity. Because the commands to an online Syscoin node. inputs need to be valid in the UTXO database this means that the inputs need at least 1 network confirmation to ensure 1.7.6. Multiparty encryption through multisignature that the owner is indeed the one who is the one capable of aliases. An alias makes a symmetric group key K, which making these transactions. In order to improve usability, 5 extends to multiple parties through the use of multisignature (an arbitrary number) of outputs are created upon an alias aliases where the key K becomes known to all members of transaction so that multiple service transactions relating to the alias by virtue of sending to each member the encryption an Alias Identity can be made within the same block on the of K with his public key. This happens upon update or network. The alias consensus code ensures that the public activation of a multisignature alias. You may begin with a key of the alias input to the transaction matches the public normal alias and extend multiple parties to offer viewership key of the alias. This validates the one who is making the of private data such as certificates or via the encrypted transaction to modify or update an Alias Identity. message service or you may revoke the privileges by simply managing which aliases belong to the multisignature alias 1.7.2. Public and private profile data. Aliases have public signature list in the alias settings screen. and private profile data. Private data is encrypted to the All encryption done in Syscoin is done based on encryption public key stored in the alias which is generated Elliptic Curve Integrated Encryption Scheme(ECIES) with upon activation of that alias. The encryption private key is the secp256k1 curve. It is the same curve used by the Elliptic itself encrypted to the alias public key so only the owner Curve Digital Signature Algorithm(ECDSA) algorithm in of the alias can view or change the encryption key used to Syscoin used for signing transactions. The symmetric decrypt sensitive private data. Encryption keys are stored public key encryption allows the alias service to become separately so that group encryption becomes possible with the keystore to manage and distribute encryption keys multisignature aliases. See section 1.6.6 for more details on conveniently without involving any complexity with the group encryption. user. It is also good to note that the curve secp256k1 (a non- conventional Koblitz curve) is not the same as secp256r1 1.7.3. Ratings. Ratings are provided (ranging from 1 to 5 which was used everywhere as standard at the time of inclusive) which keep a count of ratings per user perspective Bitcoin’s creation. Satoshi was smart enough to know that or being a merchant, buyer or arbiter. The count divides using secp256k1 non-standard curve was the better choice. the accumulated rating value based on each role to come We now know in hindsight that secp256r1 involved a seed up with a fractional number between 1 and 5. Feedback c49d360886e704936a6678e1139d26b7819f7e90 [Pacb] and ratings play a key role in identifying actors which are which is linked to the backdoor found in Dual-EC-DRBG rational and provide willingness for other actors to work linked to the NSA (thanks to Edward Snowden) [Per]. Even with them through marketplace activities. the late Hal Finney questioned the use of a non-standard curve in 2011 not knowing the link between the seed used 1.7.4. Transfer ownership. Aliases may be transferred to in secp256r1 and the NSA [Fin]. Thus the encryption in another public key. A new public key can be generated on Syscoin is based on a strong security protocol that other the alias screen from the receiver. A public key cannot be encryption mechanisms may not share. shared amongst multiple aliases which would cause con- fusion in the wallet. Thus at the consensus level transfers 1.7.7. Alias authentication. An aliasauthenticate RPC are checked to ensure the new public key of the alias does function is provided to the user that takes in an alias, and a not already exist in another alias inside of the Syscoin alias password and gives a private key of that alias. Alias private database. keys can be generated deterministically by supplying a
password. If an alias is deterministically created or updated, on the time being accurate and reliable as a form of tool the aliasauthenticate RPC can be used to retrieve the private to use to detect when an Alias expires. All other services key from any node on the network. It essentially regenerates connect to aliases and use the alias that owns the service to the private key and validates that the public key of the alias detect expiry. Offers, certificates and messages expire when and public key of the generated private key match to prove the alias related to it expire and escrow will expire if and it is the correct password/alias combination passed into the only if both buyer and seller aliases involved are expired. function. This is useful for retrieving your private key if you This prevents the case where the seller cannot complete es- do not have access to your wallet and is part of a bigger goal crow because buyer becomes inactive or where buyer cannot of being able to transact on the blockchain with walletless complete refund because seller is inactive. As a result of nodes. The listing functions of Syscoin such as offerlist, using time for expiry, you may create Aliases which expire certlist, escrowlist all take in alias or an array of aliases at certain timestamps which allow many unique use-cases on to list information pertaining to those services through the the blockchain with time-expiring contracts, provably linked distributed Syscoin services databases. They are not depen- to Syscoin service lifetime. Of course the longer you set the dent on the wallet to detect which information to display. expiry into the future the higher the fee you will pay(see the A private key can be passed into these functions which fee structure above in section 1.6). The fee is dynamically are used to decrypt sensitive information such as buyer linked to the alias rate peg used for an alias and can adjust notes and private data from certificates or aliases. The only to market demands. requirement Syscoin currently has with wallet is to display a list of your own aliases and making transactions to update 1.7.10. Alias rate peg. By default new users will be able to your services. The Signrawtransaction RPC function is an use sysrates.peg which the Syscoin team will manage and example of a transaction-creating function which potentially update with the most commonly used currencies and pay- creates a new keystore to sign transaction inputs if private ment options based on an algorithm that determines update keys are provided to the function and serves as a wallet-less frequency based on volatility of the underlying currency and transaction mechanism. Similarly, Syscoin transaction cre- assets in the rates alias. Service fees (inside the SYS object ation routines can do the same thing to remove dependence of the data model) are included to allow dynamic control on the wallet. Doing so opens up interesting designs such of the Satoshi per Byte requirement of Syscoin service as the ability to login (via Syscoin’s Aliasauthenticate RPC transactions. This allows for the service rates to be adjusted function) to a secure website (https) that is trusted by the using the standard Alias Update API as the market demands. user (perhaps their own website) and create transactions with This avoids the need to change rates via costly code updates their services over the Internet running on a server hosting a and forking changes across the network. The updates happen wallet-less node. Thus the server security requirements and in real-time and take affect across the network in 1 block. thus costs are reduced to just preventing the DDOS attack. For example, if the target price of 1 USD dollar per Syscoin Since no user keys are stored on the server, the majority is achieved: the default value of the fee is 4000 Satoshi’s per of incentives for hackers are removed from the design. byte and for a 2kb transaction populating an offer related This fulfills the vision that Bitcoin developers set out for transaction that will be about 0.01 Syscoins after taking into when creating the Signrawtransaction RPC function with the account the minimum relay fee and mining fees. That would ability to sign with any private key. Because remembering a equate to about 1 cent USD for each update. Now if the password is much easier than the private key, the usability of value went up to 100 dollars USD the fees can be reduced alias authentication brings wallet-less transactions into light. to 40 Satoshi per byte to keep the service fee at 1 cent USD. What makes the system democratic is that any Alias Identity 1.7.8. Safe search. Two tiers of marketplace moderation can be associated with any other peg rates alias which may both user-defined via SafeSearch and team-defined via a offer a rate more indicative of current market sentiment. 3 tier system. The moderation system allows for a more Because the owners of Alias Identities can adjust which public-friendly marketplace with options for SafeSearch re- rate peg alias to associate their alias with at will or even stricted items. The client can choose if they wish to enable change which alias an offer belongs to which possibly or disable SafeSearch through the wallet settings. Any actor changes which rates peg that offer will use, careful network that is adding content that is not suitable for searching for checks must be performed to ensure that payments are cor- the public can set his or her offer to private which will hide rect across all offers being accepted on the network. When it from the searches but keep its validity on the network just distributed consensus checks are performed, the block height as any other offer. at which the payment was made in, is saved and used as an index to look up the current rate peg for the Alias Identity of 1.7.9. Expiration. Alias expiry happens based on time. the merchant and then price is matched with what the buyer The blockchain protocol acts as a decentralized time server paid. If there is a discrepancy between what the buyer owes which stamps blocks based on height and time. We leverage for an offer and what the converted rate is calculated to the time component of the forging of the block which is be for that block then the buyer is displayed given an error backed by an enormous amount of computing work which message on payment. This allows for deterministic payment cannot be modified without redoing the work (Bitcoin’s behavior to ensure merchants that payments are in correct whitepaper showed this is not feasible). Thus we can depend amounts without having to do cumbersome manual check
for every payment of an offer. information, it becomes almost natural to think that hook- ing them up with multisignature Aliases would allow for 1.7.11. Multisignature identities. In Syscoins identity sys- Certificates to now be fully functional. Indeed that is what tem (Aliases) we store the public key, the number of sig- we did. We have extended the functionality of offers, mes- natures required and redeemscript which are an integral sages, certificates and aliases to allow for full multisignature part of the multisignature signing process. Without these ownership. pieces of information which links the parties involved, a multisignature transaction cannot be signed and sent to the 1.8. Certificates network. In Bitcoin these pieces are all handled offline and if forgotten or misplaced, leads to permanent forfeiture of Digital Certificates on the Syscoin blockchain are useful the coins stored in a multi-signature address. for all kinds of things from storing bits of data to creating Syscoin extends multi-signature functionality through data that may be sold and automatically transferred upon Alias Identities by paying to a multisignature transaction purchase- all with proveable ownership via the blockchain. rather than using a Script Hash (P2SH). Because P2SH does not have enough information in it to know who needs to 1.8.1. Categories. Certificates also use categories like offers sign and how many signatures are required, it forces users however they are restricted to using a certificate category to send this information to each other using a cumbersome defined in syscategory alias. The alias acts as a dynamic raw transaction API. Although we can send the information mechanism to update the category system in Syscoin. A using encrypted Syscoin Messages it is still a hinderance for certificate must set its category to a certificate or any of its mass adoption of any technology built using multisignature sub categories. The syscategory alias is used by offers and features of a blockchain based project. Everywhere a pay- certificates to populate possible default categories that can ment is done, a redeem-script is looked up from the payment help in organizing information so it becomes searchable. address as an alias identity and used as a destination instead of the address destination. Taking this approach simplifies 1.8.2. Public and private data. Certificates like aliases the process of using multisignature transactions and leads have public and private data. Usually if someone is to sell a to a more flexible approach on how to best use it- surfacing certificate they would have a public section as a preview of new use-cases which increase real-world productivity. the data that is encrypted which would need to be paid for to A new user interface has been developed to let you be accessed. Private data can be accessed by foreign aliases sign a multisignature transaction, allowing inspection of either through creating a multisignature alias and including the transaction including any Syscoin service related in- other aliases or by transferring ownership of the certificate formation, before signing. It is now easy to implement a to the new owner. By changing the alias of the certificate Know-Before-You-Sign policy which allows users to simply to point to a new multisignature alias created by the owner check the decoded transaction before signing it. Indeed which he assigns 2 aliases he owns and one of the party any multisignature transaction that is signed should not be wishing to read the data, it would allow the owner to control trusted regardless of who is involved, it should be decoded access to the certificate while still allowing decryption of and checked prior to signing and sending to the network to the private data. If the external alias were to try to change avoid unscrupulous behavior from bad actors who spend the the certificate he would have to get signatures from either coins held in escrow in undesirable ways. of your aliases which are part of the signature list of the By creating an Identity system which supports required multisignature alias now controlling the certificate. However multisignature details we can fix the deficiencies in the since you would have control over 2 of the 3 aliases in Bitcoin Core which blocks multisignature transactions from the signature list you would still retain control over the the transaction ledger and spending selection screens such certificate allowing you to revoke readability privileges of as Coin Control. This allows for a more intuitive user the foreign alias experience of multi-signature transactions at a core level. Everyone from novice to experienced users will appreciate 1.8.3. Transfer ownership. Certificates can be transferred the intuitiveness and convenience of not having to send just like aliases. However you may transfer certificates to details to responsible parties to be able to sign and send other aliases for convenience. New owners will receive read- multi-signature payments on-chain. ing rights for any private encrypted data. The transfer can As a result Syscoin Aliases now support multisignature be configured to allow editing of certificates upon transfer. ownership. By combining an identity system and multisig- If it is enabled then new owners will be able to edit the nature transactions we have an easy to understand system certificate otherwise it will be locked from updating upon that allows users control over their identity while providing transfer. maximum flexibility in terms of real-world usage. Although the blockchain in many ways simplifies business processes 1.9. Escrow and finds newer and better ways to solve problems, we still cannot get around things that involve multiple parties Syscoin’s integrated escrow service allows safer pay- holding sensitive information. Until now. Because Syscoin ments of offers by securely holding a buyer’s coins in escrow Certificates were made to store these sensitive pieces of until the terms of the sale are met and as a result the buyer
releases payment to the seller. In most cases no dispute is filed and no arbiter action is needed. The buyer chooses the arbiter and seller would agree by sending goods or services to the buyer upon which buyer would release payment and seller would collect. Escrow works with native payments in Syscoins as well as external payments with ZEC/BTC by signing transactions inside of the Syscoin network and posting to the appropriate network once the escrow contract is complete. Arbitrated escrow as illustrated in figure 1 shows the use of a arbiter which acts as a trusted third-part between buyer and merchant for a sale in the decentralized marketplace. An arbiter is paid based on a dynamic fee set in the rates peg for the offer that is sold. The normal escrow transactions which do not involve the use of an arbiter does not pay arbiter any fees because they were not involved in doing any work related to the escrow process. However if the arbiter does get involved and issues a refund or release transaction they will be paid the fee. At the end of the process of completing an escrow all three parties can be rated and given feedback related to the sale. An arbiter can override a refund Figure 1: Syscoin’s arbitrated escrow service transaction by also re-issuing it if the merchant creates a malformed refund transaction that does not pay the correct 1.9.1. Escrow Support on external payments. The mul- amounts back to the buyer. The same thing applied to an tisignature escrow feature works nicely with our Di- arbiter being able to re-release escrow funds back to the rectBTC/DirectZEC integrations which allows signing and merchant if the buyer acted unscrupulously. sending raw transactions to the Bitcoin/ZCash networks respectively and spending those coins, all via the Syscoin Escrow acts as a zero-sum game between the buyer and network. In Syscoin Escrow, if a user wishes to pay via merchant in the exchange of goods. If you denote the goods Bitcoin or ZCash they would pay to a generated P2SH being exchanged and the price paid for them as 1 unit (1U) representing an escrow address. The raw transactions to then we can summarize the exchange of units as follows: spend those coins to the merchant/re-seller for commission and buyer for refunding any escrow arbiter fees would all be done in Syscoin. The involved parties would simply • 1. Buyer creates an escrow for goods or service. -1U click a button to complete their role in the escrow. Fully • 2. Merchant transfers goods or service to the buyer. signed payments are sent to the Bitcoin/ZCash networks -1U automatically upon release/refund with no manual merchant • 3. Buyer receives goods or service. +1U interaction required. The merchant’s payment address is • 4. Buyer releases escrow payment to the merchant. convertable to BTC or ZEC and all they need to do is import +1U their Syscoin merchant private key into a ZEC/BTC wallet to be able to spend their offer payments. You can see that at the end of the escrow process that 1.10. Offers and decentralized marketplace the zero-sum game is complete for both parties. We have developed a marketplace where you can se- If merchant does not ship goods, the arbiter simply curely and reliably buy and sell any items you wish. Entire refunds the buyer. If the buyer receives goods and it is as stores can be created directly through the marketplace where described but doesn’t release payment, the arbiter simply you can sell your own products or re-sell others products for releases funds to the merchant. Of course there is no system commission that is fail-safe from irrational behavior so due diligence needs to be taken on the part of both the buyer and 1.10.1. Offers quantities. All Vendors have different re- merchant to prove without a reasonable doubt if they had quirements for inventory control. In order to satisfy as many been cheated. The feedback and rating system helps prevent use-cases as possible, we have implemented both finite irrational behavior by aligning incentives such that it allows and infinite quantity controls. A vendor can enter a finite actors to benefit if acting honestly. In other words, buyers inventory of 1-x which matches their physical inventory and will not buy from merchants that are justifiably rated badly that inventory will be reduced by -1 on every completed and merchants will not sell to buyers who do not seem offer purchase. If the offer is digital in nature or there is an honest. An arbiter which earns fees will only be used if unlimited physical supply, the vendor can enter”-1” which they are reputable as well. will indicate and allow unlimited offer purchases.
1.10.2. Alias rates peg. The sysrates.peg alias is used by the whitelist and can add a discount level on a per entry basis default in all offers as it will be managed and updated for each reseller. If the merchant sets his offer to private, by the team providing fiat and BTC or ZEC price updates then end-users must purchase the item through one of the regularly based on a metric of volatility and time. Setting participating resold offers. the currency of an offer looks up the conversion rate at the time of sale and applies it in taking coins from the 1.10.6. Feedback and rating system. Escrows and offers consumer sending to the merchant. However since the offer sold through the marketplace offer a convenient way to rate consensus code can look up what price peg was used and and leave feedback on a per sale basis. For an escrow, at which block height, it has the ability to detect that a one rating is accepted (a number from 1 to 5) representing correct payment was made at any given time. This means satisfaction of the sale from 1 being the least satisfactory any other nodes synchronizing from a previous block will to 5 being completely satisfied and recommending the user be able to deterministically detect payments and discard to others. Ratings and feedback can be given to and from those that do not pay enough from bad actors. Because the arbiters, merchants and buyers. Up to 10 feedback’s are relationship between the conversion rate that the sysrates.peg allowed to be left per sale for each type of user and are will use holds over time it can be thought of as a traditional public for anyone to see via the Syscoin API. For a normal fixed exchange-rate pegging system (to SYS) [Wik]. If the sale, buyers and sellers may rate each other once and leave consensus code was not there to maintain the relationship up to 10 pieces of feedback for each other. Ratings and of the asset price to the Syscoin price at the time of feedback help bolster the reputation of those involved in the payment, then there would be no correlative relationship marketplace to increase acceptance of those users amongst and would be a simple conversion-at-purchase tool. It is each other. It is an integral part of a system that is based much more than that and deterministic payments across on global users who may never interact with each other multiple assets including custom ones will allow for flexible physically. payment options and help ease the transition for consumers and merchants from traditional marketplace environments 1.10.7. Multiple payment options. Syscoin currently of- to cryptocurrency ones. The whole goal of the rates peg fers 3 payment options which can be used in combina- feature is to provide convenience, should demand for a new tion. Syscoin, ZCash and Bitcoin are currently the three fiat token or asset arise, not only can we provide that easily offers options for payment. Syscoin is the native token and in the sysrates.peg at our convenience by updating the alias as acceptance of the network grows, the token of choice public data but anyone else can create an alias peg and have for payments. However to achieve network effect Bitcoin others associate their offers with it. This makes it a trust- was added which has the highest liquidity of any crypto- less design that doesn’t depend on the teams rate peg which currency. It allows a vast community of users to use Syscoin is just done for bootstrapping users with defaults that will services with little to no cross-chain configuration. ZCash is make life a little easier for those who are getting used to helpful for anonymous payments and was also added in the the decentralized marketplace and how it works. same way Bitcoin was. The private key of the merchant of an offer is the same private key used for payments 1.10.3. Offer currencies. When creating an offer on the in Bitcoin and ZCash. The ease of use and convenience marketplace you can choose which currency the item should it provides makes this feature a key part of the potential be priced in. The price is internally stored in Syscoin growth and network effect for Syscoin services. The low amounts and converted to display by the conversion rate barrier of entry makes it likely that these communities will defined in the peg rate alias associated with the identity use Syscoin services and recommend others to use it. It is that is used to create the offer. It is important to note that important to note that the design of the payment options payment happens in either BTC, ZEC or SYS but not in is trust-less. A trustful design would have been to allow any other currency that is simply used for the convenience payments in other currencies or tokens by exchanging to of price display. If the rates peg is updated, the display price a desired token of choice by the merchant. The obvious will adjust for any new conversion rate. drawback is that trust must be placed on the exchanging medium to convert tokens as well as suffering conversion 1.10.4. Digital sales. Certificates may be sold in conjunc- and slippage making it less enticing to use any token other tion with offers to create sales of digital ownership. A than Syscoin. This makes it an ideal choice for external certificate may hold private information such as codes or communities to use services without suffering loss through registration keys that are redeemed for some service by conversion and security breaches which may reduce margin the buyer of the offer. The certificate may be automatically to become unprofitable for merchants in the long run. transferred to the buyer upon completion of sale. 1.10.8. Private payments via ZCash. Because Syscoin 1.10.5. Reselling with whitelists. Merchants may leverage addresses are compatible with ZCash Transparent addresses a whitelist feature to offer resellers the chance to sell their we can offer ZCash support with complete multisignature offers for a commission. This allows drop-shipping of goods support to allow for optional Syscoin escrow functionality. A and services while offering provable sales through the de- merchant has the ability to select a combination of payment centralized marketplace. The merchant of the offer controls options from a list of SYS, BTC or ZEC. Once a buyer tries
to buy the offer they will see the payment options available. ship the product and give the notification to the buyer to Once they select ZEC, a Transparent ZCash address will be expect the goods or service soon with a tracking number generated which uses the same private key as the merchants sent via the encrypted messaging system. Of course there is Syscoin address. The buyer would pay from a private ZCash no requirement of how the acknowledgement is to be used address to preserve anonymity and the seller would import or if it needs to be used at all, it is a convenience feature their private key (at a random time in the future) into their that allows the merchant to acknowledge and perhaps notify ZCash wallet to claim their funds, and send those funds into the buyer of actions that the merchant has taken upon sale. an input of a JoinSplit transaction to store them in a private Perhaps merchants will adhere to a convention of how to ZCash address, creating a JoinSplit sandwich. use this feature as the network grows and becomes adopted The JoinSplit sandwich can be summarized as follows by more users. z-addr to P2SH t-addr to z-addr which provides the max- imum amount of privacy with multisignature support. All 1.10.10. Categories. Offer categories can be anything the signing of ZCash transactions within the Syscoin escrow user specifies. However the notable exception is if you are service happens on the Syscoin network and is posted onto selling a certificate they must be a certificate category or the ZCash network upon escrow completion. This offers sub-category. Default categories are defined in the syscat- great usability within a trust-less and decentralized payment egory alias and updated by the Syscoin team to provide a design. dynamic mechanism of updating categories in Syscoin based The ”sandwich” of Pours around a t-addr transaction on market demands. however this leaks the amounts involved, which an adversary could then correlate with other information such as timing 1.10.11. ”Wanted” section. If you have an item or service and transport layer metadata. The correlation can be easily that you are looking to buy but cant find it on the mar- voided by randomizing when to complete the second Pour ketplace you can list it in the wanted section. The wanted to complete the ”sandwich” by sending the t-addr funds to section will have multiple subcategories such as Wanted a privacy preserving z-addr. Services or Wanted Items etc. If a seller matching your The process of remaining entirely anonymous is easier needs sees your wanted listing they can simply create an for the buyer than it is for the merchant. The buyer sim- offer fitting your wanted request and get into contact with ply sends coins from a private ZCash address and retains you via the Syscoin encrypted messaging service to proceed anonymity. The merchant’s process involves generating the with the transaction. This makes a bidding market that will merchant Syscoin alias through the use of a faucet (This allow multiple merchants to contact the buyer and have the preserves the merchant’s identity since there is no way to buyer choose the desired offer to purchase the wanted item. link a merchant to a physical identity through the use of The buyer will choose between merchants with the lowest a faucet). The involved parties would operate over TOR price with the best feedback, thus it may not always be the which is supported by the Syscoin core wallet for security at lowest price wins. The merchants may also add discounts the network packet layer, to avoid giving up the buyer’s or to the specific customer if the offer is intended to be a merchant’s physical location. Once they create offers and get live public listing available to anyone. This would be done paid by a merchant which pays from a private ZCash address through the whitelist mechanism of the offer if they wish to the merchant’s public Syscoin address. The merchant to reduce the sale price for the specific buyer for whatever would then import his private key into a ZEC wallet and reason (most likely wholesale purchases where more than 1 convert those funds back into a private ZCash address at a qty is sold). random time by doing random amounts until the full amount is converted (perhaps by simply waiting for multiple sales to 1.10.12. Private offers. Private offers are useful for hiding accrue before converting to z-addr funds). Doing so prevents offers from public viewing and searches. They also have a a timing analysis attack which allows third parties from role for when a merchant of an offer acts as a wholesaler linking the payment to the merchant to the private ZCash to whitelist affiliates. If the wholesaler sets his offer to converting process of the same amount some time later. private, the affiliates can themselves have their commission This timing attack may be relevant only to those merchants based offers set public however buyers will not be able that repeatedly sell offers for the same amount of coins to directly purchase from the wholesale offer directly but and send those coins to private ZCash addresses with some must operate a sale through one of the affiliates of that uniform pattern of time and amounts. By simply waiting offer. This mocks the real-life wholesaler/reseller/distributor for multiple sales and/or splitting transfers to private ZCash model where affiliates and wholesalers come to agreement addresses randomly, timing attacks on the leaked amounts on discounts and commissions and proceed to sell goods on can completely be mitigated and full complete anonymity the marketplace without worrying about being cut out by retained for the merchant. buyers directly purchasing from the wholesaler because it would be cheaper to do so in most cases. 1.10.9. Shipping notification system. A payment acknowl- edgement button on escrow and offer payments allows a 1.10.13. Marketplace moderation. Marketplace modera- multi-use notification system to the buyer that either the tion is done through the SafeSearch feature which allows merchant acknowledges payment and/or they are about to for 3-tiers of moderation which is affected by the use of a
sysban alias that the Syscoin team owns. The users of the are used to determine the keys for encryption. The sender network are able to set services to SafeSearch but if they and recipient keys are encrypted with the message so that no are creating content not suitable for viewing and not using third parties can read the data transmission without having SafeSearch then the team can moderate these such pieces of the private key of either of the parties involved. Multiparty data to remove from public viewing. It is important to note encryption is also possible through the use of multisignature that the sysban moderation does not disable the services alias identities. See section 1.7.6 Multiparty encryption. from use on the network just that it becomes publicly unviewable and omitted from searches similar to how private 1.11.1. Send raw hex. Because of multisignature aliases, offers work. The sysban alias itself is a multisignature we needed a way to be able to transfer raw transactions alias which ensures that not one but a group of people on to other signatories of that alias in a private and efficient the Syscoin team need to arrive at a consensus regarding manner. Utilizing the encrypted messaging system made filtering content. This can later extend to a committee of sense but the problem is that there are only about 6300 people that can act as guards of safe viewing which would bytes allowed to go into a Syscoin service transaction and have the sole jobs of applying moderation or reviewing the message needs to be stored twice, one encrypted to moderation activities. the sender and one encrypted to the recipient. Because raw transactions are stored in binary it would make sense to be 1.10.14. Offer geo-location. All Syscoin offers include a able to send raw data which can be decoded as hex by the placeholder for WC3 standardized (longitude/latitude) data. recipient allowing transactions as big as 6000 bytes to be Because of the global nature of the blockchain, there are encrypted and sent as raw binary data and decoded as hex many scenarios in which Syscoin services would require by the recipient when using to sign with the multisignature a geolocation. A user on the marketplace may wish to signing tool in the alias screen. Sending as raw binary data search for offers within a defined radius of their current instead of hex halves the size of the data transmission size as geolocation, look for offers in a location they are travelling hex is represented by 2 characters for each byte. When this to, or look for offers within their country for shipping option is checked, the raw binary message is encrypted to concerns, and additional use-cases. The current desktop the recipient only and not the sender to save space. The application does not enter this data automatically, as desktop recipient can see the message and copy it and sign the computers normally do not contain the hardware required to transaction safely and securely. UTXOs that are used by retrieve GPS data. While this data could also be obtained that transaction are locked on the senders wallet to avoid from IP address and Service Provider data it would not be the sender inadvertently spending those outputs on other very accurate. This data would currently need to be entered spending transactions before the signatory signs and posts manually. It has been included in the 2.1 release to allow the raw transaction to the network. development to continue on mobile/web applications which will have access to GPS data. 1.12. Blockchain pruning 1.10.15. Dynamic fees. Escrow arbiter and transaction fees Bitcoin has an option pruning feature which is quite for transactions are part of the rates peg alias which are different than what we describe here. Perhaps Segregated updated by default in the sysrates.peg alias. Merchants are Witnesses(Segwit) is the closest related thing to Syscoin’s free to use whichever rates alias suites their needs but pruning mechanism because it saves bandwidth as well as buyers may choose not to purchase from merchants using storage costs. Just as Segwit splits transactions into two offers connected to rates aliases which are not maintained with just a hash of the Witness transaction that is carried properly or have ludicrous fees. Services which need to forward by SegWit compliant clients for consensus validity, look at historical fees to determine payment amounts like Syscoin’s pruning mechanism works similarly with service escrow and offer payments look up what the fees were at transactions by splitting the Syscoin service transaction into the time of payment. Transaction fees are used for escrow 2 outputs. One is the ownership provable output which links related transactions which depend on what the market rate the service to a public key that is capable of modifying the for mining fee are at the time of sale. They are set to service linked to the information in the output. It is a small Satoshi per byte amounts. For example a Bitcoin external scriptPubKey which carries just the important information payment must pay at least 60 Satoshi per byte otherwise needed to prove that you own a certain alias. Every other parties involved in the sale will be waiting for hours if not service is linked to an alias which extends provability to days for the transactions to confirm. On release of Syscoin services outside of aliases. In the figure below you can see 2.1 the Bitcoin transaction fee is set to 75 Satoshi per byte the two outputs. Output 1 has just the alias output which in sysrates.peg for quick confirmation of payments. linked to an owner public key. The OP code denotes the type of service it is, a name and guid to be able to lookup 1.11. Messages the alias from the Syscoin service DB and a hash of Output 2 which is the data carrying OPRETURN representing the Encrypted messages use asymmetric cryptography to data in the Syscoin transaction. Offers, certificates, mes- send data to alias public keys. The identity system plays a sages, escrow all create similar Output 1 style outputs with key role in messaging because senders and recipients aliases different OP codes, but they all must have an output for
the alias which proves that the owner of the alias is the one 2. Future work making the transaction linked to any service. The consensus code will extract the data from Output 2 and check to see Depending on the demand for Syscoin services there are that the hash matches from Output 1 to ensure integrity of some useful features that can be added with minimal effort the data from data mutation attacks. Doing so will let us but intentionally left out due to time constraint for the 2.1 effectively not have to hash the contents of Output 2 inside Core release. This would invalidate all regression testing of our blockchain transaction. The data must be available and would require further unit tests for code coverage pur- on demand inside of the database and it remains so until poses. There is some work to integrate Syscoin services to expiration where it is assumed it will no longer be needed complement Segregated Witness functionality which helps because updates to services are disallowed if expired. A scale the transacting mechanism of Syscoin with sending combination of using prunable outputs with expiration of and receiving coins. Although Syscoin Core supported the services allows us to create a unique pruning mechanism functionality of SegWit it was left out intentionally until we that will save new nodes syncing from having to download develop unit tests surrounding the testing of this feature to and store expired service data. From preliminary tests run ensure integrity across service usage. on node4 of our unit test suite shows that data savings are Perhaps a use-case we have to research for the use of remarkable. Node4 is the node that is set to txindex=1 which SegWit would be to allow updating Syscoin services offline, disables the Syscoin pruning mechanism. As the unit tests in case people want to make many small edits and then run this node will save all of the pertinent service data inside finally post onto the network UTXO database once finalized. of its database as per design. In a later test, we’ve run it as This would allow the amount of data carrying outputs to be txindex=0 meaning pruning is activated and synchronized minimized to the data that only needs to be settled for others a new client to it. Since most of all services were expired to use when using those services. running the unit tests the new node synchronized very little We are also investigating using quantum resistant sig- data from node4. After synchronization of the blockchain nature schemes. Perhaps switching Bitcoin’s native ECDSA was complete we noticed the data directory size of node4 which may be vulnerable to attack from the NSA [Paca] to being 335Kb while the new node only 470 bytes while still a Merkle Signature Scheme such as the Improved Merkle maintaining complete protocol consensus. Signature Scheme (CMSS) which is faster(up to 10x faster than ECDSA) and quantum resistant. A Merkle Signature Scheme combines the one-time signature scheme (either Lamport or Winternitz) with a Merkle tree (also called a hash tree). This allows us to use one public key to sign many messages without worrying about compromising security. 2.1. Messages Currently anyone on the network can send anyone else messages. It would be useful if certain identities disallow the general public from messaging to them so they would not have to filter through messages they do not care for. This is a trivial change that involve only allowing replies with previous message inputs attached if some option is set in the recipients alias identity settings. 2.2. Auctions Figure 2: Syscoin OPRETURN data hashed into UTXO An auction type offer would allow for applications such as real-estate and Ebay style sales to take place. The three auctions types would be Absolute Auction, Minimum Bid Auction and Reserve Auction. Note that Bidding Fee auc- tions may make sense once the Lightening Network project is released in conjunction with segregated witnesses for payment-channel style interfaces to the blockchain in the context of offers. 2.3. Escrow We felt that Deposit-less escrow was the better option for Figure 3: Syscoin Outputs not hashed by blockchain mainstream adoption but for the best consumer protection,
double-deposit escrow (DDE) may offer more piece of mind rewards reducing them to 16.39 per block (a reduction of to both sides of the party who wish not to rely on arbiters 330 percent). even with positive feedback. This type of escrow requires some upfront deposit of funds which may or may not be The mining rewards, designed to be gradual and smooth, destroyed on contractual disagreement. Because of this it end at about 800 million coins (block 24177646 will happen offers incentive for both sides of the party to complete the near year 2052) and thereafter supply is inflated via the agreement under mutual agreement. However it does take Syscoin mechanism design of the inflation/deflation system away incentive to use it because it requires upfront deposits. assuming services are in high demand. As described in It also would not work without some sort of time-bomb section 1.5.1 if the number of Syscoin service transactions is extension so that funds aren’t destroyed inadvertently by 5 or less the mining algorithm will burn the service fees and absent stakeholders. This complicates the design and we above 5 will start to inflate the fees to the supply and give felt that simpler is better in regards to escrow especially to the miners. This way the supply can accommodate high since feedback becomes helpful with arbitrated escrow. It demand for usage on the network without relying entirely may be useful for mid-valued transactions that offer better on traditional fees for miner incentive to produce blocks value of security. DDE can simply be an option for escrow honestly. Currently the block size being 1MB and maximum and can be added as desired if the market shows demand service data size being about 6300 bytes it will equate to for it. Allowing any other crypto-currency to be able to roughly 158 services per block possible at full block capac- use the escrow service along with payment options through ity. Since blocks are produced every minute that works out the offer service is also something to look at and do an to 2.6 transactions per second (TPS). If SegWit or Lightning analysis on based on the volume and demand of some coins Networks improve the TPS such that it becomes 100 TPS as they move up the ranks. With the flexible design of or more, we may have meaningful inflation statistics that Syscoin escrow it makes it fairly trivial to support other affect the network supply in a noticeable manner. At current coins, especially those that share the same private key format rates the inflation or deflation produces using the algorithm as Syscoin (like Bitcoin and ZCash taddr’s do). remains negligible until future innovation allows the design to be complete. For now the total usable supply as described 2.4. Aliases by the miners will be 800 million with possibility of future expansion up to 888 million once we are able to improve Alias identities can make use from wallet-less transac- the transactions per second of Syscoin services. SegWit will tions that allow payments and updates to service to take be possible upon the Syscoin 2.1.2 release. place without the need for users to have access to their wallet. This may make sense in shared key environments where the user may wish to login (with their alias identity password) to a portal managed by an identity or certificate issuer and the user may use Alias Authentication to prove ownership of an identity and use their Alias Balance to send a sign a spending transaction. There is more information on this in the Syscoin Use-Case paper under Future Use-Cases. 2.5. Certificates Using torrent trackers and other P2P style hosted data source is something to research as it will allow for scaling certificate data above the limits of 1KB of data for private encrypted information while maintaining security through the network. Storing data can be encrypted to the public key of the certificate owner which is the alias identity it is assigned to. This way data can be hosted in public rather than on private servers that are maintained with rigorous security to avoid breach of access. 3. Specs There is a 888 million maximum coin limit. 1 minute block time. Proof-of-work SHA-256 merge mineable (ma- jority of network security coming from Bitcoin). Syscoin 2.0 had a block reward of 54.13. Syscoin 2.1 which was released on December 18, 2016 represents a ”halving” event in block Figure 4: Syscoin mining schedule
4. Conclusion [Nie] Jakob Nielsen. Nielsen’s Law of Internet Band- width. URL: https://www.nngroup.com/articles/ We have presented a set of hardened smart-contracts law-of-bandwidth/. that can be used in conjunction with each other and an [Paca] Chris Pacia. Bitcoin vs. The NSAs Quantum Com- identity system to provide blockchain-based e-commerce puter. URL: http : / / www. bitcoinnotbombs . com / solutions for small, medium and large businesses. The pro- bitcoin-vs-the-nsas-quantum-computer/. cesses used by businesses and entrepreneurs may transfer [Pacb] Chris Pacia. NSA Backdoors and Bitcoin. URL: to Syscoin without the need to re-invent the way people https://chrispacia.wordpress.com/2013/10/30/nsa- work today. The goal is not to force the technology and backdoors-and-bitcoin/. processes on the people using it but to bring people to the [Per] Nicole Perlroth. Government Announces Steps technology who are in need of a blockchain-based solution to Restore Confidence on Encryption Standards. to their problems. The mix of unique features of Syscoin URL : http : / / bits . blogs . nytimes . com / 2013 / 09 / in an architectural framework that enabled high security 10 / government - announces - steps - to - restore - through merged-mining and low inflation enabled trust-less confidence-on-encryption-standards/? r=1. payments and services to be used today in commercial [Wik] Wikipedia. Fixed exchange-rate system. URL: ventures and partnerships as well as provide an investment https : / / en . wikipedia . org / wiki / Fixed exchange - proposition to holders of Syscoin token holders. A low rate system. barrier of entry for external communities can be leveraged [Wil] John Williams. Shadow Government Statistics. to help create a network effect for Syscoin and its services. URL : http://www.shadowstats.com/. Acknowledgments We would like to thank Satoshi Nakamoto, the late Hal Finney and Gavin Andresen for bringing Bitcoin protocol and reference client to mainstream adoption state. Without the work of these people none of what we have worked on with Syscoin would have been possible. A special thanks for the Blockchain Foundry Inc. team of Sebastien Dimichele, Chris Marsh, Brad Hammerstron, Willy Ko and Dan Wasyluk for their peer review and up- dates. References [Nas02] John F. Nash. “Ideal Money”. In: Southern Eco- nomic Journal 69.1 (2002), pp. 4–11. DOI: http: //www.jstor.org/stable/1061553. [Nar16] Arvind Narayanan. “On the Instability of Bit- coin Without the Block Reward”. In: ACM CCS (2016). DOI: https : / / www . cs . princeton . edu / ∼smattw/CKWN-CCS16.pdf. [But] Vitalik Buterin. DAO Vulnerability. URL: https : //blog.ethereum.org/2016/06/17/critical- update- re-dao-vulnerability/. [Cry] Cryptoid. Syscoin 2.1 block explorer. URL: https: //chainz.cryptoid.info/sys/. [Dai] Philip Daian. Chasing the DAO Attackers Wake. URL : https://pdaian.com/blog/chasing- the- dao- attackers-wake/. [Deva] Bitcoin Core Developers. Bitcoin reference client. URL : https://github.com/bitcoin/bitcoin. [Devb] ZCash Core Developers. ZCash. URL: https : / / github.com/zcash/zcash. [Fin] Hal Finney. secp256k1. URL: https://bitcointalk. org/?topic=2699.0/. [Nak] Satoshi Nakamoto. Bitcoin: A peer-to-Peer Elec- tronic Cash. URL: https://bitcoin.org/bitcoin.pdf.