US SEC takes position against developers of smart contracts

It’s said that just because it looks good on paper, doesn’t mean it looks good in practice. This adage could hold true, in a way, for smart contracts. While they aren’t actually written on paper, their original design is proving to enjoy a more theoretical victory than a real-life one. Nick Szabo, who was originally behind smart contracts, has started to question if they make sense and even Ethereum’s Vitalik Buterin is someone turned off to them. Now, it appears that the U.S. Securities and Exchange Commission (SEC) isn’t behind them, either, and could actually prosecute someone who develops a smart contract – even if that person doesn’t use it.

In its Statement on Digital Asset Securities Issuance and Trading, which was published last Friday, the SEC asserts that a smart contract provides “the means for investors and market participants to find counterparties, discover prices, and trade a variety of digital asset securities.” It made several references to the contracts, pointing out how it has already prosecuted someone, Zachary Coburn, for “operating an unregistered securities exchange” using smart contracts that he had coded.

Coburn ran the Etherdelta decentralized exchange (DEX) and was fined $400,000 by the SEC. While the case seems to be straightforward – he was operating an exchange without approval – there’s more to it than that.

According to the Friday statement, the SEC states, “An entity that provides an algorithm, run on a computer program or on a smart contract using blockchain technology, as a means to bring together or execute orders, could be providing a trading facility. As another example, an entity that sets execution priorities, standardizes material terms for digital asset securities traded on the system, or requires orders to conform with predetermined protocols of a smart contract, could be setting rules.”

Therefore, someone who develops a smart contract could potentially be held liable for any activity that takes place on the contract. If computer code was once viewed as a form of free speech in the U.S., those days could be over.

Szabo recognizes the issue smart contracts are facing and suggests that he understands how a smart contract developer could be held liable. He said in a Twitter post last Friday, “‘Smart contract’ like ‘contract’ connotes a deal between people, but a deal intermediated and incentivized by dynamic machine-interpreted rules instead of the statically recorded human-interpreted rules of a traditional contract.”

Based on the stance of the SEC, which will certainly grow bolder moving forward, it would appear that smart contracts aren’t so smart, after all.

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post US SEC takes position against developers of smart contracts appeared first on Coingeek.

Read More

Blockchains in the enterprise: Smart contracts in different chains

This is a guest contribution by Jeri DeBitto. If you would like to submit a contribution please contact Bill Beatty or submission details. Thank you.

Smart contracts

This next section of the article will deal with the issue of smart contracts and how they are implemented in the different blockchain systems which are popular in the current industry.

Most of the purported benefits from blockchains are ostensibly the promise of smart contracts on blockchains. Smart contracts are the ability for logic to be executed on the blockchain itself (by its main validators or a subset of these) which will enable basic payments upon fulfillment of the conditions which are necessary to make simple settlements automatic. The simplest example of these is the payment upon some external condition being met (which requires the use of trusted information sources, called ‘oracles’. ) such as in simple binary options such the EitherOr option or simple wagers where the payouts are static. But even these are complex when you consider the most basic of smart contracts. One that is so basic and taken for granted that most people wouldn’t even consider it a contract. I am speaking of course of the basic atomic swap.

The atomic swap, where 2 parties can exchange 2 legs of a deal settlement without any risk is normally facilitated by a 3rd party. That 3rd party or escrow, ensures that while the payments or deliveries from the parties may happen at different times in reality, neither party has access to the settlement until both parties payments have been mutually confirmed. This is one case where blockchains can uniquely add value as they logic in transactions can ensure that the 2 payments are made simultaneously, and also the transparency of the blockchains can ensure that neither party has any reason to distrust the smart contract code which will execute the settlement.

We will now examine the smart contract capabilities of several blockchains (both private and public) and gauge their fitness to be used in business applications.

R3 Corda

Corda is the private blockchain offering from R3 which was written explicitly to handle smart contracts between a trusted group of validators. As the blockchain and the contracting language are in Kotlin, a relative of Java, Corda stands to have the most easiest and expressive set of tools to create smart contracts. However, as Corda is not a public blockchain, it’s scope may be limited to companies which have already prearranged to trust each other in the building of a shared ledger system to manage their business use case.

Ethereum

Ethereum is ostensibly where most of the current efforts in smart contract development is taking place. This is mostly in part due to the reason that Ethereum was created with the intent of being able to create smart contracts which could not be done on Bitcoin itself due to the fact that core developers disabled the programming abilities in Bitcoin (BTC). Originally Vitalik Buterin, Vladimir Zamfir, and Gavin Wood proposed an extension system that could be built on top of bitcoin to facilitate smart contracts, but the bitcoin core developers at the time were against this use of the bitcoin blockchain and pushed changes that would block their idea, forcing them to create a new blockchain entirely, ETH.

Currently ETH has the most smart contract developers mostly in part to the fact that the blockchain is publicly shared (and therefore permission-less) and also because there are several languages which are available to write smart contracts in, javascript, python, and go, which all compile to a common virtual machine bytecode for execution (EVM). This is much like the java/JVM model. The most popular smart contract template in the ETH ecosystem is the ERC20, which is a basic fungible token, with additional logic that can be tailored. Many ICOs, and utility tokens are created using ERC20. The only drawback of this popularity is that most of the tokens created have questionable legality or are straight up scams. However, due to the fact that the ledger is public and permission-less, there is nothing that can stop people from creating such tokens.

Bitcoin Cash

Recently, bitcoin native smart contracts have once again been made possible due to the Bitcoin Cash fork, which has re-enabled many of the original smart contract capabilities originally put into Bitcoin by the creator(s). Many of these programming features were disabled in 2011 after the creator Satoshi Nakamoto left the project and handed it over to Gavin Andresen who then allowed many such edits to the original code base by other developers who were afraid that too much functionality in Bitcoin itself would be a threat to the system’s stability. Since the 2017 hard fork which split off BCH from BTC, BCH has had 2 upgrades which brought back many of the old functions of original Bitcoin, and with the upgrade in November (BitcoinSV) promising to enable the final last set of codes which will allow for full smart contract capability to be built on top of Bitcoin again. Since Dr. Craig Wright announced to the world in 2017 that Bitcoin actually was Turing complete others have since come forward and confirmed this fact. It’s just not Turing complete in the sense of an atomic transaction, but rather complex smart contracts can be encoded in a sequence of bitcoin transactions which in turn create other transactions. This revelation has renewed the interest of developers to explore how and what the smart contracting capabilities of Bitcoin can be, and some active projects are working on custom Bitcoin smart contract compilers which can take smart contract code written in a more traditional high level language and produce low level bitcoin script which can then be embedded in a sequence of transactions. This is a relatively new field of research and there is expected to be many new developments in the near future on this front. The promise is rather enticing; the ability to create smart contracts which can be settled directly on the bitcoin blockchain without any overlay system.

Stellar

While not many people will think of Stellar (a clone of Ripple) as a smart contract platform, some significant advances have been made on the side of Stellar to make their platform capable of simulating the effects of smart contracts. As Stellar was originally a clone of Ripple, they inherited the base layer which had token creation/transfers. Ripple was originally designed for the ease of creating IOUs which were intended to be currencies. Although they have limited ability to write logic around the transfer and issuance of these IOU tokens, the creation of them by any party was always a native feature of Ripple. Stellar took this and added some additional basic rules which could be applied to the tokens, and with smart use of transaction sequencing, multi-signature escrow-ed accounts, and time locked transactions are able to do some basic smart contracts such as atomic swaps and joint-entity crowdfunding. It is however unable to execute smart contracts independently without the use of trusted escrows to manage the execution of the contracts, as their contracts need the actions of trusted third parties to ensure that the transactions are executed faithfully. It is arguable whether or not these are truly “smart” contracts. Perhaps it would be more accurate to call them on-chain digital contracts.

Scalability

The big concern for institutions evaluating smart contract platforms is whether or not they are suitable for their needs. Institutions generally value scalability in the base design because the costs of migration from a legacy system and the disruptions to the business can be restrictively costly and is a constant concern. Therefore we shall evaluate the scalability of the blockchain platforms and their abilities to scale to high volumes as well as their ability to handle different levels of smart contract complexity.

R3 Corda

Corda, being a private blockchain run by a group of validators (which they call Notaries) can easily scale to levels which a traditional shared multi-user database can achieve. The scaling issues that face public blockchains don’t normally affect private blockchains such as Corda. But since the applications of a private blockchain are necessarily of a different scope from that of a public blockchain, businesses that are willing to sacrifice application scope and direct B2C applications (where retail customers access the blockchain directly) a private blockchains scalability is enticing. Measurements vary, but private blockchains range anywhere from 15-1400 tps in terms of transaction processing speeds. The complication with this metric is that as blockchains have different ways to measure when a transaction initiates and completes depending on the definition of finality that they employ, it is hard to objectively use this metric to compare blockchains. It is relatively safe to consider other private blockchain platform competitors such as Hyperledger to be in the same performance and feature domain. The main benefit of a platform like Corda, however, is that they have full expressivity in terms of creating smart contracts, and in the case of Corda specifically, focuses on binding the legal representations of smart contracts as an intrinsic characteristic of the smart contract itself, so that it can have the best and smoothest integration with existing legal systems. For enterprises which are considering just porting over an existing system to a blockchain model, Corda seems to be a good consideration.

Ethereum

The biggest scaling hurdle facing Ethereum is that the platform takes the absolute maximal approach of having all validators execute every smart contract transaction from everyone on the network. While this method ensures maximal decentralization of the validation process ensuring that there is the minimal chance that a transaction can be blocked or double spent, it does put an undue scaling bottleneck on the network. One archetypal case was when some internet developers created and launched the now infamous Cryptokitties, a tradable token which had no value except for collectible value and novelty. The sudden popularity of this token slowed the entire Ethereum network to a crawl such that normal transactions took hours to be confirmed. This case highlighted the flaws of a system which implements it’s security model by forcing every validator in the system to validate everyone else’s transactions and contracts.

Fundamental volume scaling issues aside, Ethereum is the most developed of the smart contract platforms, and due to the fact that the language for smart contracts are high level languages that developers are accustomed to, thus it lends the ability for developers to create smart contracts quickly. This benefit is sometimes a flaw, however, when some contracts which were created and launched ended up having bugs which resulted in lost or locked up funds for all those involved (Such as the multisig wallet bug and the now infamous DAO). The trade off in making smart contracts very easy to create, coupled with the fact that the blockchain is public and permission-less inevitably means certain types of smart contract applications are easier to create on ETH than on other blockchains. One such application space that of crowdfunding. Because crowdfunding can be done by creating a smart contract that has transparent rules, it is easy (some would argue too easy) to launch such a contract and start raising money. Recently there has been increased regulatory concern over the use of ICO platforms and smart contracts being used to launder funds systematically, which will continue to put some pressure and scrutiny into ETH smart contracts. Additionally, with current ETH token standards, all ownership of tokens is clearly visible on the public blockchain. Therefore, it is rather trivial to DE-anonymize token holders simply by following their token balances which are kept in the blockchain in a central registry. This may be a problem for institutions who wish to keep their token holdings private. It is likely for this reason that most institutions using ETH style smart contracts opt to run a private version of the ETH blockchain which they solely control themselves (such as Quorum, used by JPMorgan)

Bitcoin Cash

Bitcoin Cash has a unique view on smart contract scaling. While the base protocol and all base token transfers (BCH) are validated by all miners, many of the now emerging smart contract platforms on Bitcoin Cash use a “permissionless subset of interested parties” model for the validation of the smart contracts. These are sometimes called 2nd layer validation models, and they encompass all systems that make use of meta data being validated only by validators that understand the meta data, and ignored by the rest of the miners. Sometimes these systems are together referred to as “OP_RETURN” models due to their use of that op-code to embed the smart contract meta data, even though not all of them use that op-code (some use multi-signature script embedding). However, recently, due to the old disabled op-codes that were originally part of the bitcoin protocol being re-enabled in BCH by the nChain version of the protocol, ‘native’ smart contracts can now be written directly in bitcoin script, which is the native language which the Bitcoin miners execute as part of their validation process when they receive transactions.

The important difference between Ethereum smart contract model and the Bitcoin Cash model is that while Ethereum focuses on full transparency of the smart contract code for all, Bitcoin cash methods tend to focus on a model in which only the counter parties to a deal and interested parties are aware of the smart contract. While the execution part of the contract is performed faithfully by the miners (validators) or in the case of OP_RETURN models, the specific validator nodes, the actual visibility of the smart contract terms prior to execution can be sufficiently obscured from public scrutiny.

This is achieved by allowing only the counter-parties involved to keep a copy of the smart contract code on the client side, and only in the instance when they need to settle the contract will one side or the other use the code to produce a closing transaction which is then published to the blockchain. This allows contract terms to be obscured until after execution is complete, which adds security to the model as there will be less incentive for miners in the network to collude to defraud the participants compared to the situation if they were aware of the contract details. (as is the case with ETH1).

This model of contract separation between the legal terms and the execution of the contract terms is similar to the model taken by Corda, Stellar and other platforms focusing on smart contracts.

Bitcoin Cash smart contracts are the only ones that scale in direct relation to the scalability of the base blockchain itself, due to the fact that native smart contracts written in bitcoin script is code that miners execute themselves as part of transaction validation. This is a positive design decision as the more complex smart contracts which take more transactions and larger script to execute will naturally cost more in execution fees due to the sats/byte fee pricing model in Bitcoin Cash (which at writing holds steady at ~1sat/byte.)

This means that as long as Bitcoin Cash can scale itself, then smart contracts will scale with Bitcoin Cash base layer. This is in stark contrast to Ethereum, whereas the transactions costs (‘gas’ in Ethereum terms) require developer input in helping with coming up with reasonable default rates due to the complexity of using a Turing complete language at the mining/validator level. This is due to the fact that it is not trivial to come up with a computation cost metric scale for different high level language constructs, especially when looping and recursion is introduced. With a lack of a simple guiding metric based on size such as sat/byte, it is hard for a liquid market on fee rates to emerge.

Stellar

The scaling considerations surrounding stellar is similar to the ones that face Ripple. Ripple and Stellar use a balance account based method of ledger accounting, all transactions just effect a delta on accounts. This means in order to run in a completely trust-less way (such that any node starting from zero could verify independently the balances of all accounts) all transactions need to be kept. Additionally one of the features of Ripple/Stellar is the fact that the order system and book is built into the protocol itself. This means that in addition to actual payments and trades, the order states themselves is a transaction that must be stored on the ledger. Because of this extra information (compared to the simple UTXO model used in Bitcoin) the ledger is very large (in the case of Ripple, 7TB in size and growing at a rate of 1GB a day). The scaling issues with Stellar therefore, is less with the consensus layer and more at the storage layer, and how to manage the ever growing blockchain data store.

The second issue with Stellar is the open question on how to scale their public permission-less blockchain in a way which is decentralized. Of course if all new nodes were to just adopt a closed set of validators which are trusted then the system will be free of ledger forks, and enjoy maximal consistency of data (as discussed in Section I). But to do so means that the set of trusted validators must be known beforehand and coordinated. Also if a critical number of trusted validators were to have a byzantine fault, then the ledger would partition and it would be very difficult to detect. Furthermore, it would be quite a challenge to resolve the matter of legitimacy of a split ledger, and whether or not a re-merge of the ledger is even possible after such a fault. (Compare this to bitcoin-style blockchains which can recover and automatically re-merge after a ledger split)

Another issue with Stellar is that they lack a native smart contract language and interpreter as part of the base validation engine. The Stellar application of smart contracts is more akin to using high level transaction pre-signing and time lock manipulations in order to effect the desired business use case. Therefore more complex smart contracts are not possible as of this time. In fact, due to the fact that Stellar lacks a built in “executor” process for smart contracts, it is fair to say that their contracts aren’t ‘smart’ at all. However, with timelocks and multisignature transactions one can compose a good number of basic use cases which normally fall under the realm of ‘smart contracts’ such as crowdfunding and atomic swaps.

Summary of Smart contract native capabilities of blockchains (red: private, green: public)

Blockchains in the enterprise: Smart contracts in different chains

* Not readily possible given the private nature of the blockchain

** Possible only through the use of a third party escrow signer.

1This does not preclude the possibility that ETH will create smart contract templates that mirror this design philosophy in the future. It just is an observation from the existing smart contract market of the current state of affairs of ERC20, ERC223, ERC721, ERC777, ERC820 tokens.

Editor’s Note: This is the second in a series where Jeri Debitto explores and evaluates blockchains in the corporate environment. In case you missed the first article, you can read it here.

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post Blockchains in the enterprise: Smart contracts in different chains appeared first on Coingeek.

Read More

CFTC official issues warning over smart contracts, predictive code

A CFTC commissioner has warned smart contract developers that they could be held liable for blockchain functions deemed to be “predictive event contracts,” in the latest sign of regulators increasing their oversight of smart contracts.

Brian Quintenz, a commissioner at the U.S. Commodities and Futures Trading Commission, told a meeting of delegates in Dubai that old laws and regulations still apply to new technologies, and the likes of blockchain developments and smart contracts were not immune from these laws.

He noted that smart contracts can be highly customised, and can be used in place of traditional financial instruments, saying, “Essentially, these contracts would allow individuals to bet on the outcome of future events, like sporting events or elections, using digital currency. If your prediction is right, the contract automatically pays you the winnings.”

This could bring smart contracts within the ambit of the CFTC as a prediction market. Traditionally, these are prohibited by the CFTC, which sees event contracts in particular as “not in the public interest”.

Quintenz suggested that smart contract developers could be held accountable for any instruments that fall within the CFTC’s regulatory remit, saying: “Therefore, the particular fact pattern described above – event contracts, executed in a potentially for-profit manner, between retail customers, on any conceivable event, for any sum of money – raises multiple CFTC regulatory concerns.”

“If the contract is a product within the CFTC’s jurisdiction, then regardless of whether it is executed via a written ISDA [International Swaps and Derivatives Association] confirmation or software code, it is subject to CFTC regulation,” the official explained.

Quintenz said that developers should bear in mind how their smart contract would be used, and whether this would like violate CFTC regulations.

“I think the appropriate question is whether these code developers could reasonably foresee, at the time they created the code, that it would likely be used by U.S. persons in a manner violative of CFTC regulations,” the CFTC commissioner said, adding, “I would much rather pursue engagement than enforcement – but in the absence of engagement, enforcement is our only option.”

His comments come as the starkest warning yet from the regulator, which has been upping its efforts towards tackling perceived infringements of regulations from blockchain and cryptocurrency markets under its jurisdiction.

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post CFTC official issues warning over smart contracts, predictive code appeared first on Coingeek.

Read More

Dr. Craig Wright on smart contract registries

Dr. Craig Wright took to one of his favorite stages recently to talk about Bitcoin BCH and smart contract registries. In a Medium post, Wright set out to detail how smart contracts could be introduced successfully on the blockchain and did an incredible job breaking down the specifics of any registry platform.

Wright points out that one of the major issues with contract management is the overwhelming amount of redundancy. Copies of the same contract are kept in a number of different locations, which is a logistical nightmare when any change or addendum is needed. Since contracts are often written in natural language, they can also be open to interpretation if not properly dissected during the drafting phase.

These obstacles, among several others, are the reason smart contacts make sense. However, several steps must be followed to have them implemented properly.

Some of the main requirements include formal definition of the contract so that it “can be formally interpreted and implemented by a machine, as well as converted into natural language,” explains Wright. Additionally, it’s important to be able to publish a contract so that everyone knows it exists, while not divulging any of the details, except to those with the need to know.

It is also important to consider including mechanisms that allow the contracts to be configured based on time and/or conditions. Perhaps a contract is only valid for 18 months or expire once the contract’s target has been fulfilled. Smart contracts will need to know what actions to take based on these criteria if they are to be effective.

The Bitcoin BCH blockchain already includes a number of features that make contract creation a breeze. Once the proper controls are added to the contract and it is registered in a repository, “the associated URI and hash can be used in accordance with using metadata within a Blockchain transaction to associate the transaction on the chain with the controlling contract itself,” explains Wright.

To ensure that any machine-readable contract can also have a human-readable version, Wright points out that he and the group at nChain are already working on a tool that will generate a readable document. This version would be delivered in in pdf format, or something similar that doesn’t allow for easy editing.

To ensure that only authorized individuals have access as appropriate to the contract, it can be secured by several means. The most basic security is offered through a hash check to ensure that there haven’t been any alterations. Additionally, the repository itself can be locked down and the contract can be digitally encrypted to limit access only to those who have the corresponding decryption keys.

Says Wright, “In many cases, the Contract itself will have partial protection on it. For example, some sections within the file are protected but the overall content is public. For example, the details of how to implement a fixed rate loan are published but the knowledge of who took out the loan, for how much and at what rate is known only to the contracting parties.”

Wright provides further details on the intricacies of contract creation and manipulation using the Bitcoin BCH blockchain, but it’s evident from the insightful piece that Bitcoin BCH already has everything it needs to facilitate contract creation and storage, and doesn’t need any modifications to enhance the platform.

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post Dr. Craig Wright on smart contract registries appeared first on Coingeek.

Read More

Dr. Craig Wright on why smart contracts aren’t so smart

Dr. Craig Wright, an expert in blockchain technology and dedicated Bitcoin BCH supporter, took to Medium yesterday to pen a thoughtful piece on smart contracts. The insightful article provides valuable information on the topic and some of the underlying flaws in the system, and is a further example of how breaking away from the core essence of Bitcoin BCH would undermine the progress the world’s leading retail digital currency has already made.

Wright was responding to another post that asserted, “Electronic contracts do not have to be re-read when they are returned because there’s generally no mechanism (unless it’s built into the electronic process) to alter the contract terms, scratch out a line, insert text, etc. What you send is what is being signed.”

However, this assertion is flawed and shows the danger of not having enough information to reach a full and qualified conclusion. Wright points out that collisions on a blockchain have proven that a hash signature has certain inherent vulnerabilities. He states, “[T]he collision allows two versions of the document to be created with the same hash and thus same electronic signature. For now, SHA256 is considered secure, but, not all hash functions are.”

He uses an example of someone generating two documents – one with an order to sell at $500,000, which Wright calls Order 1, and the other with an order to sell at $1 million, or Order 2. The individual wants Order 2 to be the document that signed, which would result in the sale contract being increased by $500,000. That person can use Confoo or Stripwire to create an MD5 hash – or collision – that is exactly the same for both documents.

Confoo has already been shown to be able to create two web pages that look completely different, but which have the same MD5 hash. This is a concern, as it would allow someone to easily create a fake MD5 hash signature that mimics a different contract.

Wright explains, “This attack works due to the nature of hashing algorithms (in this case, a flaw in the now depreciated algorithm MD5). If you have 2 documents, x and y that have the same hash (i.e. a collision) then by appending an additional block of information — q to the documents will also result in a collision. This is (x+q) will have the same hash as (y+q).”

He concludes, “This is why SV Pool and CoinGeek (and Bitcoin SV) plan to start processing non-standard scripts. To us, your long term security matters. Non-standard scripts are processed in P2SH. The myth was that this is bad for nodes, but, this is again the myth of the Raspberry Pi. Miners are competitive. The fight to be paid. [They] are paid more for larger scripts, so this is not an attack, it is the market at work.”

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post Dr. Craig Wright on why smart contracts aren’t so smart appeared first on Coingeek.

Read More

Block Seoul Day 1: Is cryptocurrency a new asset class?

It is apparent how cryptocurrencies are starting to change the world and how people live today. And yet, there is not much sense of urgency among governments and regulatory bodies in most territories and jurisdictions as to how these new form of money can be technically defined and used by everyone.

On the 17th of September 2018, the first day of the Block Seoul 2018 conference, a panel of investors and innovators came together to discuss what cryptocurrency is and define whether it is an asset class. The Financial Times described an asset class as a broad group of security investments that tend to act similarly in different market conditions. Equities like stocks, bonds, and cash are all asset classes.

Among the panelists, BTCC co-founder Bobby Lee and Elmar Bob from Tech Alliances APJ agreed that cryptocurrency is an asset class. Bob shared, “I’ve been living and working in Japan for about 20 years. Japan has always recognized Bitcoin and cryptocurrencies as an asset class.” He added, “In fact, in Japan Bitcoin is legal tender so you can actually buy and sell goods with Bitcoin. Now, that’s kind of an important aspect because Japan is third largest economy in the world. It’s something we need to pay attention to.”

Lee agreed and shared the possible reason why countries all of the world seem to have challenges with creating and defining regulation for Bitcoin. “Bitcoin does not fit into any one of these (securities, equities, bonds, real estate, and precious metal). It has aspects of all five of these asset classes but I think Bitcoin cryptocurrency is a unique piece that’s why countries and regulations will have a challenge,” Lee explained.

For CITDEX’s Chris Cutler, however, cryptocurrencies are assets—but they’re not asset classes. He then raised a question: “How does it fit within the regulatory framework, in the legislation framework?”

According to Cutler, there is a rich history of how investment instruments are treated under tax rules. He said, “You’ll see different treatments for securities tokens offerings that distinguish them from utility token offerings in the United States, and those are critical distinctions. It’s also frustrating dealing with governments often because they are reactive and not keeping up.”

The panel also discussed other use cases for tokens that exist in the ecosystem that have not been seen before. Trevor Koverko, of Polymath, forecast the next evolution will involve moving from paper to digital, and then to smart contracts, where programs and simple tasks as filing will be automated. Cutler also expects that security tokens will be disruptive in Venture Capital industries.

Sandra Wu, of Origin X Capital, pointed out that with Security Token Offerings (STO) there will be regulators which may only allow accredited investors, which, in turn, may defeat the purpose of a decentralized feature of the technology because it may only be about “the big boys club” again. She asked, “How do we ensure that there will be more individuals coming in and playing in this space? Because ultimately, with this type of technology, you want mass use adoption and therefore, a lot of investors coming in.”

Wu closed the panel stating the future of crypto is looking bright. She hopes to see new custody offerings and new regulations that will guide the community to a new path.

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.

The post Block Seoul Day 1: Is cryptocurrency a new asset class? appeared first on Coingeek.

Read More
Top