Coin News

What the heck is happening in the crypto world?  Is Ethereum finally dead?  Is ETH taking its last breaths?

Not likey. In fact, the recent pullback on the ETH-USD market is probably one of the best and healthiest things investors and traders could have asked for. Given ether’s 300% price rise in just over a month, this pullback has a left many traders and investors bullish on the ETH-USD market.

On a macro-scale, we can see ETH-USD had a very nice, textbook market correction along the 50% Fibonacci Retracement Line (shown in brown).  This test of the 50% line was immediately rejected and is illustrated by the massive spike in volume (shown in blue).  

For healthy, growing markets 50% retracements are a very common occurrence, and the market response to the retracement can be viewed as a sort of litmus test for the strength of a market (i.e. a positive rejection of the 50% line with upward price action tends to indicate the market still desires higher prices, and a negative move from the 50% line will typically indicates the market is still extended and thus overvalued).

Figure 1:  ETHUSD, GDAX, 12HR Candles

Looking at the micro-trend, we see the strong price rejection bounced off the 50% Fibonacci Retracement Line and is currently in the process of forming what is known as an “Inverse Head and Shoulders” pattern. This pattern gets its name simply because it has the following, easily identifiable characters:

• A well defined neckline (shown in yellow)

• A break of the descending trend line (shown in brown)

• A left shoulder, a head which makes the lowest peak, and a right shoulder

• A re-test of the neckline (at the time this image was made, the market was testing the neckline)

• Finally, to confirm the reversal pattern, volume usually needs to increase after the re-test of the neckline to gain strength in the upward movement.

Figure 2:  ETHUSD, GDAX, 30Min Candles

This sort of pattern is often traded in FOREX and stock markets because it is seen as a reliable and predictable indication of future price movement.  Typical price projections for Inverse Head and Shoulders are easily calculated with the following formula:

Price Movement = Price of the Neck Line (~$350) - Price of the Head (~$250) = ~$100

Price Target for Trend = Price Movement + Neck Line Price = $450

Given the strength of the macro-trend’s rejection of the 50% Fibonacci Retracement Line and the current pattern forming on the 1-hour charts, we must then look to other indicators to give us further market insight. Two commonly used momentum indicators, RSI (Relative Strength Index) and the MACD (Moving Average Convergence Divergence), show us that the price increase from the initial, aforementioned 50% Fibonacci Retracement Line rejection is welcomed with a rising trend on both momentum indicators; this shows us that the price growth still has upward momentum.

Summary:

1. Although the sudden price drop was a bit terrifying for many investors and traders, it was much needed and has now shown the strong market value of ether.  

2. Now that we have proven the strength in the market, it is very likely we will see new price highs in our future before we see further tests of lower prices.

3. On a macro level, ETH-USD sentiment still remains bullish; on a micro level, we are seeing strong indications of a trend reversal from the sudden bear market over the past few days.

Bitcoin’s long-lasting scaling debate appeared to be heading toward a climax lately, with two proposals gaining significant traction. At one end of the fence there is Bitcoin Improvement Proposal 148 (BIP148), a user activated soft fork (UASF) originally proposed by the pseudonymous developer “shaolinfry.” On the other, there’s SegWit2x, an agreement forged between a significant number of Bitcoin companies and miners.

The good news is that both of these proposals have a short-term solution in common: both plan to activate Segregated Witness (SegWit) this summer. The bad news is that the activation method of the two has differed, which could lead to a coin-split.

As of today, it seems this schism will be avoided — at least initially. The SegWit2x development team plans to implement BIP91, a proposal by Bitmain Warranty engineer James Hilliard that cleverly makes the two conflicting activation methods compatible.

Here’s how.

BIP141

The current implementation of Segregated Witness is defined by BIP141. This version is included in the latest Bitcoin Core releases, and is widely deployed on the Bitcoin network. BIP141 is activated through the activation method defined by BIP9. This means that 95 percent of all blocks within a two-week period need to include a piece of data: “bit 1.” This indicates that a miner is ready for the upgrade. As such, SegWit would be activated if the vast majority of miners are ready for it.

Or that was the intention. So far, only some 30 percent of hash power is signaling support for the upgrade. There is a lot of speculation as to why this is the case, but it almost certainly has nothing to do with (a lack of) readiness.

That’s why other activation methods are increasingly being considered.

BIP148

BIP148 is a user activated soft fork (UASF), specifically designed to trigger BIP141.

On August 1st, anyone running Bitcoin software that implemented BIP148 will start rejecting all blocks that do not include bit 1, the SegWit signalling data.

This means that if a mere majority of miners (by hash power) runs this software, they will reject all blocks from the minority of miners that does not. As a result, this majority of miners will always have the longest valid chain according to all Bitcoin nodes on the network. Consequently, all deployed BIP141 nodes will see a chain that includes over 95 percent of bit 1 blocks, meaning SegWit would be activated on the network.

However, if BIP148 is not supported by a majority of miners (by hash power), Bitcoin’s blockchain could split in two. In that case, there would effectively be two types of Bitcoin, where one activated BIP148 and the other did not. This may resolve over time — or it may not.

SegWit2x

SegWit2x (also referred to as “SegWit2MB” or “the Silbert Accord”), is the scaling agreement reached by a numer of Bitcoin companies and over 80 percent of miners (by hash power), drafted just before the Consensus 2017 conference.

For some time, the details surrounding SegWit2x were not very specific. As the name suggests, all that was really known was that SegWit was included in the agreement, and that it included a hard fork to double Bitcoin’s “base block size” to two megabytes.

And, of course, SegWit was meant to be implemented using a different activation method. Like the original BIP141 proposal, SegWit2x was to be activated by miners through hash power. But where BIP141 requires 95 percent hash power support, SegWit2x would only require 80 percent. Moreover, SegWit2x readiness would be signaled using another piece of activation data: “bit 4” instead of “bit 1.”

This makes SegWit2x largely incompatible with BIP141, and especially with BIP148: Different nodes would be looking at different activation bits, meaning they could activate SegWit under different circumstances and at different times; and that would mess up SegWit-specific block relay policy between nodes, potentially fracturing the network.

BIP91

Now, it seems BIP91 has provided the solution.

BIP91 is a proposal by Bitmain Warranty (not to be confused with Bitmain) engineer James Hilliard which was specifically designed to prevent a coin-split by making SegWit2x and BIP148 compatible.

The proposal resembles BIP148 to some extent. Upon activation of BIP91, all BIP91 nodes will reject any blocks that do not signal support for SegWit through bit 1. As such, if a majority of miners (by hash power) run BIP91, the longest valid Bitcoin chain will consist of SegWit-signaling blocks only, and all regular BIP141 SegWit nodes will activate the protocol upgrade.

Where BIP91 differs from BIP148 is that it doesn’t have a set activation date, but is instead triggered by hash power. BIP91 nodes will reject any non-SegWit signalling blocks if, and only if, 80 percent of blocks first indicate within two days that’s what they’ll do.

This indication is done with bit 4. As such, the Silbert Accord can technically be upheld — 80 percent hash power activation with bit 4 — while at the same time activating the existing SegWit proposal. And if this is done before August 1st, it’s also compatible with BIP148, since BIP148 nodes would reject non-bit 1 blocks just the same.

This proposal gives miners a little over six weeks to avoid a coin-split, under their own agreed-upon terms. With a SegWit2x launch date planned for July 21st, that should not be a problem… assuming that the miners actually follow through.

Bitcoin exchange and hosted wallet provider Luno (formerly BitX) is developing a Bitcoin scaling solution called Moonbeam. Unlike the lightning network, Moonbeam does not require SegWit’s transaction malleability fix and would be able to operate on the Bitcoin network as it is today.

Moonbeam  aims to provide a way for multi-user Bitcoin platforms — such as exchanges, hosted wallets, and payment processors — to easily open standardized one-way payment channels with each other, and thereby offload the Bitcoin network from a growing number of transactions.

How Does it Work?

Moonbeam aims to take advantage of the fact that many Bitcoin transactions occur among multi-user platforms. Using Moonbeam, these platforms can open standardized one-way payment channel contracts with one another to facilitate payments. By taking these transactions off-chain, Moonbeam can reduce transaction fees for those who use it and benefit Bitcoin users generally by reducing congestion in the mempool.

These channels are simple smart contracts in which one party locks up a certain amount of bitcoins for a specified period of time (with the end point referred to as the “timeout”) for the purpose of sending payments to the other party. Before the timeout, the party that has locked up funds can send an unlimited number of off-chain transactions using those locked up bitcoins (until the channel runs out of bitcoins). Each channel involves only two on-chain transactions: one to open the channel and one to close it.

Because these intermediate transactions are off-chain, they are nearly instant. Without the need for a blockchain confirmation, the transactions only take as long as it takes to route an http request (think: loading a simple web page). These transactions would also be cheap. Only two transactions per channel require miner fees, and the rest are essentially free to the platform, though the platform could charge fees to its users.

The one-way payment channels used by Moonbeam are not a new invention. Bitcoin inventor Satoshi Nakamoto embedded preliminary code for payment channels in the very first release of Bitcoin, and more recent protocol upgrades like CheckLockTimeVerify have further enabled this usecase. Bitcoin platforms could negotiate and implement these smart contracts on the blockchain today.

What Moonbeam aims to do is facilitate the creation of these channels between major payment platforms by using the Domain Name System (DNS) to route communications related to creating and using these channels. This way, high volume platforms can easily discover one another and enter into a payment channel smart contact using the standardized Moonbeam terms. Using the Moonbeam protocol, this process can happen automatically when it is more efficient to open a channel than sending payments on-chain.

Trust

The Moonbeam project overview indicates that it is “semi-decentralized.” It is labeled as such because while the Moonbeam network does not require platforms to trust one another, it does require users to trust their platforms. A hosted wallet with a Moonbeam address is a custodial account, where the platform is managing the funds, and credits and debits user accounts accordingly as users send and receive transactions. Exchanges such as Coinbase operate in this manner; users do not directly control their private keys. Moonbeam can be a useful tool for these services, but it will likely not be a suitable scaling solution for users who prefer to manage their own private keys.

Other Downsides

The Moonbeam specification document also mentions several other potential downsides. Among them is the cost of capital. In order to open these channels, sending platforms must commit capital in the form of bitcoin for a period of time. If the receiver does not use the channel, the sending platform must wait until timeout to regain control of the funds, entailing potentially large financing costs.

Another risk involves the use of DNS. DNS hijacking is an attack that involves rerouting domain name requests to an attacker’s server. These attacks could be used to receive payments over new channels that were meant for the authentic server.

While Moonbeam does not offer the level of decentralization of the lightning network, the fact that it does not require any fork to the network may may make it an attractive solution to Bitcoin’s scaling troubles in the short term. It could be implemented by hosted wallet providers as soon as the project is production ready.

The current state of Moonbeam can be found on the project’s Github.

Luno was not available for comment for this article.

In my last post, I was talking about how connecting all blockchains is the final stepping stone for mass-crypto adoption. Here I want to outline the technical building blocks with which this idea can be implemented.

Since I see a lot of downsides to having one large uber-blockchain connecting all others, I will focus on a token-LESS solution. This would have several advantages:

• No need for an additional token.

• Users can “remain” on their blockchain.

• No need to trust a centralized third party.

There are a couple of downsides to such an approach however. Since there is no uber-blockchain or a centralized party ensuring the connection, there needs to be enough liquidity between two blockchains to be connected. If I want to transfer funds from the Ethereum to the Bitcoin blockchain, for example, I need someone who, at the same time, wants to go from bitcoin to ether. For these two large blockchains, you will always find someone willing to go in either direction, but what about from Ethereum to a smaller blockchain or a small blockchain to another small blockchain? While I will be laying out a way on how that could even be solved, I want to stress that liquidity is the key economic factor in such a cryptographically secure multi-asset network.

Basic Building Blocks

Let’s look at the three very basic building blocks that are needed to connect any two blockchains:

1. Multisignature feature (Multisig);

2. Hashing functionality; and

3. Time-lock functionality

Let’s work through each of these three and combine them into a larger single picture.

1. Multisig is an old and well-trusted concept that can be compared to a shared checkbook with multiple required signatories. A multisig transaction allows for the enforcement of arbitrary joint signature rules. In the case of a cryptographically secure, off-chain, multi-asset, instant transaction network (COMIT) one would use 2-of-2 multisig transactions for which both signers have to sign a transaction to become valid and be accepted by the network (an example of this will follow right after). This means a multisig transaction established between two parties needs to be signed by both so that its outcome becomes valid and can be accepted by the network.

In the picture below, a transaction was created with 1 BTC as input; however, in order to get it out, both parties (Alice and Bob) have to sign the transaction:

2. Hash functions are standard cryptographic concepts. These are one-way functions to convert arbitrary data (in our case a secret “s”) into a unique hash “h.” This hash h can then be shared safely without anyone being able to compute the secret s used to create it. This allows us to build a hash-lock transaction which will only unlock the funds with the knowledge of the secret s. In order to route across different blockchains, we need the same cryptographic hash function available in the smart contracting language of each blockchain participating on such a route.

In the picture below, someone put 1 BTC into a contract, but Alice can only take it out once she has the secret (which she normally would get from Bob).

3. Time-lock is a simple requirement for funds to be locked up until a future date. Blockchains are found to have two different time-locks: relative and absolute. Absolute time-locks will lock a transaction output until a fixed point in time in the future, whereas relative time-locks will lock a transaction output relative to an event or a point in time. That is to say, a relative time-lock rather defines a time span than a specific point in time. Time-locks are a requirement for trustless payment channels, and relative time-locks are recommended as they allow for indefinitely open payment channels.

In the example below, someone put 1 BTC in, but in order for Alice to get it out, she has to wait a predefined time. 

Putting It Together 

If we go ahead and combine these three building blocks, we get something called HTLCs (Hashed Time-Lock Contracts) whose states can be updated on a multisig basis. HTLCs combine the concept of a time-lock for refund purposes with a hash-lock. If the recipient can provide the secret s for the hash-lock before the expiry of the time-lock, he will be able to retrieve the funds. Otherwise, the sender can safely reclaim the funds. In case one party wants to update the HTLCs state, he needs the other party’s approval (signature). This is how the multisig function comes into play.

In the example below, Alice put 1 BTC into the contract with Bob. Bob can either take the 1 BTC out if he gets the hash from Alice within a predefined time, or Alice will get the funds back automatically after that predefined time has past.

Two HTLCs can be coupled with each other resulting in something called atomic transactions. To do so, the recipient first generates a secret s and computes its hash h. Subsequently, the recipient will share this hash h with a sender who in turn creates the first conditional transaction, i.e., its output is (hash-)locked by h. This output can only be redeemed with the knowledge of the secret s.

In layman’s terms, this would mean that if Bob wants to send Alice 1 BTC and wants ETH in return, they could open two payment channels (one with BTC and the other with ETH) and couple them with a hash h. Bob sends Alice BTC as long as she sends him ETH. In case either one backs out, the original amounts would just be returned.

The Full Route 

Now we can stack an arbitrary amount of transactions onto each other as every node in this chain can safely use the same hash to create a transaction which is also conditional on knowing the secret s. This hash is initially shared with the sender, who will then subsequently send a conditional payment to the first node requiring knowledge of the secret s to redeem it. Each node in the route can then safely forward the transaction while adding the same condition to the transaction redemption. Through the use of HTLCs we can guarantee that either all of the transactions via this route get fulfilled or all payment channel transactions will be unredeemable. No trust has to be put in any of the nodes in the middle of the route. In the end, you have a chain of transactions which all depend on the same secret to be fulfilled. When the receiver takes the last transaction and uses the secret to redeem the money, every other node will see the secret that was used and can then fulfill their own incoming transaction.

After the secret s has been shared across the route, every payment channel will then settle the transaction back into the channel. This is done by updating the payment channel’s state to the final balances and then invalidating the HTLC transactions by revealing the invalidation key k to the payment channel counterparty, which will eventually make the transaction complete.

The time-lock mechanism is used as a refund mechanism in case of an intermittent routing failure. The time-locks need to be stacked from receiver to sender to make sure no one is able to cheat by having a shorter period than someone after him/her and thereby being able to pull out first.

Conclusion 

These transactions can span within the same blockchain, but can also go cross-chain as long as you find someone who is willing to transact on both blockchains. This is where the concept of liquidity and routing comes in. To go back to the beginning where we thought about connecting two low-liquidity blockchains we see now, that we actually don’t necessarily transact between those two directly. By using stacked payment channels one after the other, money could flow from one low liquidity chain to a high liquidity chain and then to the final low liquidity chain. 

This concept connects payment channels to a large network that is now:

• Cryptographically-secure (relies on cryptographic standards),

• Off-chain (like the Lightning- or Raiden-Network) ,

• Multi-Asset (cross-chain),

• Instant (no need for a transaction to settle on the blockchain as updates only happen between the parties until it gets broadcasted)

• A Transaction Network, such as COMIT.

In the next blog post, I will talk about the concept of liquidity and Liquidity Providers (LP) and also on how routing through such a network could work.

This is a guest post by Dr. Julian Hosp, the co-founder of TenX and co-author of the whitepapers of TenX and COMIT. The views expressed are his alone and do not necessarily reflect those of Bitcoin Magazine.

Blockchain technology has morphed from a popular buzzword to a technology that is in the process of revamping a wide range of operational and business processes within the financial service industry. A segment of the financial industry that could benefit greatly from the implementation of the distributed ledger technology is the wealth and asset management sector.

The global accountancy firm Ernst & Young published a report on the benefits of blockchain technology for the wealth and asset management industry titled ‘Blockchain Innovation in Wealth and Asset Management.’ The report states that the implementation of blockchain technology would likely result in reduced operational expenses, elimination of redundant yet time consuming functions and more opportunities to better the client experience. More specifically, using blockchain technology in important areas such as the client onboarding process, the creation of model portfolios, the settling and clearing of trades and compliance processes related to AML regulations can all be improved by implementing distributed ledger technology-based solutions in the wealth management industry.

Blockchain Use Cases in Wealth Management

In this report, Ernst & Young highlights two use cases as examples of the benefits of the blockchain.

Firstly, blockchain technology can be applied to digitize and streamline the customer onboarding and profiling process. Strict regulatory requirements require wealth managers to collect information such as proof of identification, marital status, residency, sources of wealth and political ties from new potential clients. This can be a cumbersome, long-winded and, therefore, costly process.

If, instead, high net-worth individuals’ data were to be stored on a distributed ledger to which permissioned parties could gain access with the individual’s approval, then this would greatly reduce the time and cost of onboarding a new customer. Furthermore, due to the immutability and auditability of the blockchain, an audit trail could easily be kept for each client.

Secondly, the blockchain could facilitate the creation of portfolios and the communication of portfolio changes to clients. Currently, wealth managers use a variety of different platforms to create and maintain portfolios and most of these platforms do not enable direct communication with the client.

Hence, by developing and implementing a blockchain solution that allows wealth managers to create and manage portfolios according to clients’ stored investment constraints that also allows for direct communication with regarding portfolio changes, the entire investment process would be made substantially more efficient and client relationships could be deepened due to an increase in direct communication between the wealth manager and its clients.

There Will Be Hurdles for Adoption but First-Movers Will Benefit

The report also highlights the challenges of adoption that the technology is likely to encounter. Scalability, interoperability with legacy systems, security and accordance with technology standards were the largest issues raised by the firms polled by Ernst & Young.

In addition, wealth and asset management funds do not exist in a bubble and are usually interconnected with other firms. Therefore, a wide-scale adoption would likely take a long time, considering there would have to be a consensus as to what type of blockchain solutions the whole financial industry chooses to adopt. Due to these factors, most firms are currently only willing to test blockchain technology on a small scale before considering a broader adoption of the tech.

Ernst & Young, however, believes that firms that are the first to adopt blockchain technology will reap the lion's share of its benefits. As the success of financial blockchain solutions depends on its participants, E&Y encourages firms to begin the innovation process early as first-movers are likely to benefit the most.