Your Crypto News on Steemit November 16, 2017

• What is the Lightning Network?
• Check Point: Crypto Miners are Malware!
• Man Group: Soon Crypto Futures "Made in UK"?
• Mastercard working on a Patent for instant Blockchain Payments Processing!
• European Securities and Markets Authority is targeting ICOs!
• Bitcoin Course Challenge Week 6

---

What is the Lightning Network? I have heard this question from friends often and in this article, I will try to explain in general terms how this Bitcoin scalability marvel works.

From the Lightning network you hear only the very best. This concept, it is said, solves all the scalability issues of Bitcoin, improves privacy and allows instant transaction.

Yes. That is said and that is not wrong. But if someone promises you to explain the Lightning network "simply," you can be sure you have a liar in front of you. Because the Lightning network is not easy, but complicated. But I try to make it as easy as possible for you.

At Bitcoin, each node cooks its own soup

To understand the Lightning network, we need to start with the Bitcoin network. Namely, in the fact that this is a broadcast network, which means that each node must receive, validate and store each transaction. That makes sense, but is obviously terribly ineffective.

Imagine, a group of 250 people travel from Los Angeles to San Francisco and everyone uses their own car. Or: a group of students has to complete 5 math tasks together, and each performs all five tasks. Or, one last analogy: Seven guests download the same recipe from allrecipes.com for the same asparagus soup for eight people, print it out and buy the ingredients from the same supermarket. Then they go to the host, where everyone cooks their own soup in a potty, for which he divides the amount of ingredients by eight.

I could go on forever But I think you understand where the problem is and why some people say Bitcoin does not scale.

The Lightning Network scales great

The Lightning network is now cleaning up with this problem. It forms a network of payment channels that sends a transaction only from the one sending it to the one who should receive it. That means that if I transfer money to Martin now, that does not have to be stored on every node in the Bitcoin network, but basically only on my and Martin's node. This removes some serious weaknesses of Bitcoin in one go:

• Privacy:
  At Bitcoin everyone notes what everyone does. Blockchain analyzes are possible and have a massive impact on privacy. However, if everyone only reads and stores the transactions that are important to them, the blockchain does not reveal anything about other people's money.
• Scalability:
  A broadcast network like Bitcoin can not scale or is very bad at it. More participants do not make the network more effective, but only increase the overall data load. That's why Bitcoin is unlikely to ever handle such a volume of transactions as networks like VISA can. This is easily possible with Lightning.
• Speed:
  While a Bitcoin transaction can be seen almost instantaneously, it will be confirmed after a few minutes to an hour. Until then, it is possible to reverse the transaction. With the Lightning network, however, transactions become instantaneous.

The big question is now: is that even possible? And how is this supposed to work?

The payment channels

What is a payment channel? The answer is not very easy, so I have to ask you to give me some sets of concentration. You will understand, I promise.

To open a payment channel, you and I will transfer an amount - say 0.1 Bitcoin to a 2-of-2 multi-sig-address. 2-of-2 means the following: Once the Bitcoins are at this address, both you and me need to sign a transaction to pay it off. As with a rental deposit account.

So after we have transferred the Bitcoins to this address, we will make a payout - 0.1 Bitcoin for me, 0.1 Bitcoin for you - and sign it. We do not send them to the other Bitcoin nodes, just to us. Then we modify the Bitcoin transaction again and again.

You can think of the payment channel as if I were giving you a completed remittance slip, which you can drop by your bank at any time. Instead of redeeming it, we are constantly changing this remittance slip. If I pay an invoice to you, I will not tell the bank to transfer money to you, but send you a new remittance slip to increase the amount. And so on.

Imagine that you and I have the aforementioned payment channel, in which we both paid 0.1 Bitcoin. If you want to donate me 0.0001 Bitcoin, write and sign a transaction that pays 0.0999 to you and 0.1001 to me. When I redeem the transaction, I close the payment channel. But I can leave it open and you can donate me 0.0001 bitcoin every day for a year. At the end of the year, I can close the payment channel, and you get 0.0535 and I get 0.1365 bitcoin. You have made 365 transfers, but only one lands on the Blockchain.

Such payment channels may be useful if the same two parties are always making transactions. To really be useful to the masses, we need to connect them to a network - the Lightning network. This allows me to donate a $ 5 donation to my payment channel to another payment channel route, for example, to charge my account at Bitcoin.de.

That's the idea. Before we get to how the payment channels connect, we still need to explain some challenges in setting up the payment channels. Because this one understands (reasonably) why the confusing new scripts of Core Version 0.12.1 are necessary - and why the construction of payment channels is relatively complicated, but works without anyone having to trust.

Because everything else would not be Bitcoin anymore.

Where is the problem?

There are two big issues why a payment channel does not work as easily as I've just stated. In the [white paper])https://lightning.network/lightning-network-paper.pdf) of the Lightning Network, Joseph Poon and Taddeus Dryvja explain these problems and their solutions intensively.

• The hostage-taking problem

First, imagine that you and I open a payment channel. Each of us transfers a bitcoin to the 2-of-2 Multisig address. But before you even come to send me a small donation, I show my true face and say: Hey, I will never close the channel, your Bitcoin is locked up forever, unless you send me half a Bitcoin to this or that address. The deposit of each party in a payment channel can be taken hostage by the other party.

How do you prevent this? Poon and Dryvja have found a clever solution. It sounds more complicated than it is, and once you understand it, it's easy: we first make the transaction to open the payment channel, but do not send it to the network or sign it. That is, everyone knows what's going to happen, but no one has the necessary signatures to trigger the action. The payment channel exists so far only as an idea.

After that, each of us, starting from this transaction that is theoretically present, forms the transaction that will close the payment channel. So the transaction with which each of us repays his share. If we both want to deposit 1 Bitcoin, we now form the transaction to pay each of us 1 Bitcoin. This transaction will be signed and exchanged, but not yet sent. Everyone is able to send this transaction.

Only when each of us owns the transaction (or the two signatures) with which the channel can be closed will both parties sign the transaction opening the channel and send it to the network. This means the channel can be closed by anyone at any time.

Result: The bitcoins in the channel can not be taken hostage, as either party can free them at any time. Still, this model is not possible because one needs the ID of the previous transaction to sign a follow-up transaction. But by introducing the OP_Signohash script command with a soft fork, this will be possible.

This does not solve the second problem yet.

• The problem of old commitment transactions

Imagine this time, you donate Bitcoins for 200 days to me, shifting the balance of our payment channel from 0.5: 0.5 to 0.3: 0.7. On day 201, you decide to close the payment channel. Instead of the most recent transaction, you take the first transaction, signed by both of us. The result would be that each of us gets 0.5 Bitcoin and it's like you never donated anything to me.

Poon and Dryvja have also solved this problem (theoretically). Unfortunately, that gets a bit more complicated now. But trust me, you will understand that, too.

Short to the terms: Poon and Dryvja call the transaction that opens the payment channel - ie the Bitcoin transfers to the multi-sig-address - funding transaction, and the one that closes the payment channel, Commitment Transaction. To change the credit in the payment channel, we write and sign new commitment transactions.

So as soon as we change our credits in the payment channel, there are several commitment transactions at the same time, each with the same right to the blockchain. How can you solve this problem? How do you make sure that only the latest commitment transaction goes to the blockchain?

Poon and Dryvja have developed a transaction model that penalizes those issuing an older commitment transaction by losing all credit in the payment channel. This model consists of two parts.

Firstly, you have to recognize who sent the wrong (obsolete) transaction. This is relatively simple: you just have to make two distinguishable but factually identical commitment transactions. Bitcoin's cryptographic framework makes this possible by signing inputs to each party and giving them to the other party signing the entire transaction. Imagine, I sign a piece of paper, which you put in a letter, which you then put your signature on, and vice versa. You do not need to know the details, just know the following: There are two different transactions that do the same thing. This will be important later.

Image source: lightning network white paper

Looks alike, but it is not: The purple boxes are transactions that only Alice can do while the blue transaction is reserved for Bob.

On the other hand, one has to find a way to undo "false" - ie fraudulent, contract fraudulent - transactions. The goal must be that only the most recent transaction goes through without being revoked or triggering a penalty.

Here comes a script called OP_CHECK SEQUENCE VERIFY, short CSV. This uses the sequence field of a transaction to "freeze" its output: A transaction must receive a certain number of acknowledgments before it can output its contents. For example, I can send you a bitcoin, but inscribe in the transaction that you can not use this bitcoin until the transaction has been committed for 1,000 blocks. So you hang a time lock on the transaction.

In detail it is very complicated, but with OP_CSV one can form a transaction model that allows to modify transactions under certain conditions: Each party forms a commit path with two paths. First, as agreed in the payment channel, the money is paid out to each party. This output is "frozen" and needs a certain number of acknowledgments. Second, the entire content of the payment channel is paid out to the counter party. This output can only be triggered by the other party and only after the transaction has already been sent - but it can be paid out immediately.

Image source: lightning network white paper

Purple are again the transactions that only Alice can do, while the blue boxes are reserved for Bob. As you can see, each commitment transaction has two paths, one of which can be redeemed immediately and the other later.

So if you close our payment channel with an outdated transaction, after which you get 0.5 and I get 0.5 Bitcoins, even though I should actually get 0.6 and you get 0.4, the output of that transaction will only tell after we valid 1000 blocks. However, once you have sent this transaction, I have the opportunity to pay the entire balance of the payment channel immediately to me.

This second output invalidates a commitment transaction accordingly. So if you send me 0.1 Bitcoin in the payment channel, not only will you send me the signed input for a new transaction, but also the information that will allow me to bend the previous transaction in the event that it's broadcasted Credit goes to me.

That is, as long as we both watch the payment channel, we can always tell when the other one is sending out an obsolete commitment transaction and penalizing it by redirecting all the outputs of the transaction to us. This makes it virtually impossible to send outdated commitments and penalizes the trial alone. The only problem associated with this is that both parties to a payment channel occasionally need to be online to see if the other party is risking bringing an outdated commitment transaction into the blockchain.

Conclusion

So the Lightning Network is the concept of payment channels in which we do not have to trust the other party to be sure that the latest transaction draft is the only one that will be valid.

---

Check Point Software Technologies LTD, a leading cyber security service provider, has found in a recent report that crypto-miner like CoinHive poses a threat to users. According to the JavaScript Miner CoinHive is the world's sixth most used malware.

In a press release, Check Point presents its latest Global Threat Impact Index Report, explicitly focusing on the outcomes of crypto-miners' threats. Accordingly, the use of crypto-mining as sheep software for other computers, especially in the course of October has increased again.

In an investigation, Check Point found that crypto-miners could be used to, in the worst case, claim up to 65% of end-users' computing power without the consent or even knowledge of that end-user. The most dangerous was the CoinHive Miner, which occupies the sixth place on the index. This is designed to miner the crypto currency Monero when visiting a website, without the consent of the user is required. The deduction of the computing power of the computer used, its overall performance are significantly affected.

Maya Horowitz, Threat Intelligence Group Manager at Check Point, considers the development of mining hardware to be a malware worrying. She believes that the emergence of malware in miners must result in a rethinking of cyber security. It calls for the protection and prevention to be expanded and raised to a new level by its own technology. Thus, an efficient network against cyber crime can be created. Although crypto-mining is a pity and does not go unnoticed, the impact is not less.

---

In the future, the British hedge fund Man Group intends to take the plunge into new business for crypto derivatives. This announces CEO Luke Ellis this week. This follows the CME Group from Chicago, which also announced the corresponding business expansion at the end of October. Meanwhile, the UK's financial regulator FCA again warns against the risks of cryptocurrencies. In its most recent publication, the Authority strongly advises consumers not to invest in crypto derivatives.

On CME Man followed: After the end of October, the American CME Group had already hinted at the introduction of futures contracts in the crypto sector, now also the London Man Group enters the business around the so-called crypto-futures. This reported the news service Reuters on Tuesday.

Futures are exchange traded forward contracts. They require the buyer to deliver or buy a certain amount of Bitcoin at a specific future point in time at a fixed price or exchange rate. Futures are considered to be highly risky on the stock market, as they can generate large profits in no time at the same time as enormous losses.

Luke Ellis, managing director of the fund, who claims to have assets of more than $ 100 billion for his clients, told Reuters on Tuesday:

Furthermore, he attributed credibility to cryptocurrencies. Just because they are not controlled by governments like analogous currencies would not disqualify and devaluate it, Ellis said.

The US CME Group paved the way for cryptocurrencies in the sector of options. At the end of October, the world's largest derivatives exchange announced that it would expand its business to the crypto sector, fueling current prices. According to CME CEO Terry Duffy, customers should be able to invest in the new business models and corresponding futures contracts with Bitcoin from mid-December.

British Financial Supervision once again with little optimism

As the financial industry opens to cryptocurrency, the UK authorities' response is skeptical. For example, the independent financial regulator FCA is warning of the risks of crypto currencies for the third time in the last few months this week. In addition, in an article published there website on Tuesday, the authority also specifically addresses the option and forward transactions around Bitcoin, so-called crypto-CFDs (Contracts for Difference).

While futures are safe from the legal framework, consumers should consider the possible high losses.

In the article it says:

A chance to establish?

However, these few hopeful words will most likely not deter the Man Group. When the CME Group expands its business to crypto futures in December, it will soon be followed by its British pedant.

Thus, crypto currencies and Bitcoin continue to establish themselves in more conventional financial industry market sectors. The opening of the Man Group in the UK and CME in the US shows that the expansion of the established business of established investment banks in cryptocurrencies is not halting.

Rather, it seems possible that these also establish themselves beyond options and other stock market transactions. Ultimately, it seems possible these days that in the future even large banks accept the alternative means of payment. Corresponding food for thought had been provided in recent weeks by several representatives of the "old" financial world. After Goldman Sachs CEO Lloyd Blankfein and ECB director Benoît Cœuré had emphasized that Bitcoin was taken seriously, Citigroup CEO Michael Corbat also commented positively on the future of cryptocurrency last week.

---

MasterCard's new patent application shows that the credit card giant views blockchain technology as a potential tool for improving payment processing times.

In a patent application released last week by the US Patent and Trademark Office, the company described a blockchain-based database that can process payments immediately, ensuring that merchants do not have to wait days before receiving money for their products. In addition, current information indicates that the technology should help the company to keep track of these transactions and verify that a seller was actually paid after the purchase. The stored data includes the transaction amount, a payment guarantee, confirmation of payment and account profiles of the parties involved. These account profiles also store the account balance information of each user according to the application.

Application details:

MasterCard has already considered multiple blockchain platforms to facilitate payments. Last month, the company announced that it would facilitate its business-to-business transactions by providing access to its proprietary blockchain tools. Another patent application, published in September, also related to the storage of payments using a blockchain.

---

After the German Federal Financial Supervisory Authority (BaFin) warned consumers last week about the risks involved in acquiring coins or tokens through ICOs, the European Securities and Markets Authority (ESMA) is now following up on this in a statement issued Monday In addition to repeating the risks for ICO investors listed by BaFin, ESMA also targeted ICO providers. The Paris-based agency said it was "concerned that companies involved in ICOs could carry out their projects without compliance with relevant EU legislation".

Insofar as ICOs qualify as financial instruments, it is "likely that the companies involved will operate regulated investment activities". Then they would have to meet according to ESMA according to specifications. These include the EU Prospectus Directive, the MiFID Financial Markets Directive, the Alternative Investment Fund Managers Directive (AIFMD) and the Fourth Money Laundering Directive.

ESMA emphasizes that companies involved in ICOs should carefully assess whether their projects constitute a regulatory activity under EU law. If this were the case, any non-compliance with the relevant regulations would constitute a violation. According to ESMA, it is the responsibility of the companies involved in ICOs to examine the relevant legal framework, obtain the necessary approvals and fulfill all applicable requirements.

The loop is tightening for the ICO providers ever closer. As early as the summer, the US Securities and Exchange Commission (SEC) had made it clear that ICOs may be subject to United States securities laws, depending on their design. The supervisory authorities of Switzerland and Great Britain announced that they would take a closer look at ICOs. In China and South Korea, ICOs have already been completely banned.

---

Don't miss your CHANCE to Win 💰 20 Whaleshares + 40 Hairshares💰 in the 🏆BITCOIN COURSE CHALLENGE Week 6🏆

How and where to participate? Just click HERE!

---

I wish you all a lovely Thursday!!!
ⓁⓄⓥⒺ & ⓁⒾⒼⒽⓉ
Best regards
@danyelk