If you’ve read the Lightning Network whitepaper (Joseph Poon & Thaddeus Dryja, 2016), (https://lightning.network/lightning-network-paper.pdf) then you might remember the section of that paper titled, ‘Spending from an Unsigned Transaction’.
As stated in this section of the Lightning Network Whitepaper:
“The Lightning Network uses a SIGHASH_NOINPUT transaction to spend form this 2-of-2 Funding Transaction output, as it is necessary to spend from a transaction for which the signatures are not yet exchanged. SIGHASH_NOINPUT, implemented using a soft-fork, ensures transactions can be spent from before it is signed by all parties, as transactions would need to be signed to get a transaction ID without new sighash flags.”
The reason why I posted that excerpt from the Lightning Network whitepaper is because:
A) The Lightning Network is a state channel, not a side channel (there is a difference).
B) This principle of a ‘theoretical’ payment or transaction underpins the counterfactuals that Vitalik has referenced in various EIPs (specifically, EIP 1014 ; https://eips.ethereum.org/EIPS/eip-1014)
What are Counterfactuals?
A pretty thorough overview on counterfactuals in Ethereum state channels was written a few months ago by state channels developer, Liam Horne: (https://medium.com/statechannels/counterfactual-generalized-state-channels-on-ethereum-d38a36d25fc6)
To gain a better understanding of ‘counterfactuals’, check out the following excerpt below:
We are able to achieve these results using what we call ‘counterfactual instantiation’. Explaining this technique requires first defining terminology.
‘Counterfactual’ means something that could be true, but is not. This is an extremely helpful concept when discussing state channels, where we spend a lot of time reasoning about things that could be happening on chain, but are not.
In state channels, we say ‘counterfactual X’ to describe a case where:
X could happen on chain, but doesn’t
Any participant can unilaterally make X happen on-chain
Participants can therefore act as though X has happened on-chain
For instance, imagine a payment channel between Alice and Bob. Alice sends 4 ETH to Bob through the channel, which in practice means that both parties sign a transaction.
This transaction could be deployed on chain at any time by either party, but it is not. So we can say ‘counterfactual Alice gives Bob 4 ETH”. This allows them to act as though the transaction has already happened — it is final, within appropriate threat models.’”
The Excerpt Above RE: Counterfactuals is a Solid Example of Imaginative, Unconstructive Writing
If what you read above makes zero logical sense to you - then rest assured that the problem doesn't lie with your comprehension skills.
Certain Statements That Are Extremely Problematic
For instance, imagine a payment channel between Alice and Bob. Alice sends 4 ETH to Bob through the channel, which in practice means that both parties sign a transaction
This concept is fine and dandy, but have we forgotten the other critical facet of monetary transfer that Bitcoin (and subsequently Ethereum) have accounted for in their designs?
Ensuring That Funds Can Be Spent
The purpose of the blockchain (at least in the iteration erected by Satoshi) was not to ensure that individuals were not cheating (in terms of 'committing' to their funds), but rather to provide some sort of objective means of 'accounting' accompanied with a hard-coded means of 'checking' the balance of any given entity at a given point in time (over simplifying this since there are no recipients or 'entities' on a UTXO chain).
This is what allows us to be sure that the 4 ETH that Amy is sending to Bob is legitimately in her possession because, after all, what exists to establish Amy's "commitment" to pay 4 ETH to Bob that the protocol will inevitably recognize?
Hence the Necessity of a Chronologically Ascending Block Height / Nonce Value (Bitcoin / Ethereum)
Below is an illustration that perfectly depicts the necessity of Bitcoin's (and, by relation, Ethereum) consensus mechanism:
As another block is submitted to the network (and propagated after being validated via individual nodes), we are able to refer to the latest block height as our latest viable "record" of what has been spent / unspent.
We can assert this with a high level of assurance because of the Proof of Work consensus model that underpins block production.
As we can see above, this is where the cryptographic strength of the protocol lies.
Swapping out this model out for one where we only trust Amy (because that's what we must essentially do at this point if we have nothing but a 'commitment' from Amy via her signature on a transaction - which could be stale or not) reduces blockchain down to the bank of Amy. And, worse yet, this blockchain hinges on Amy's honesty (and reliability as an arbiter of her own funds when there is every incentive in the world for her to lie).
This is Why Basterdized Solutions Like 'Elastos' Are a 'No-Go'
Take a look at the validation structure for Elastos below:
In a structure like the one presented above, we have not only added an unnecessary level of complexity to the chain, we have also entirely stripped away the benefit of Proof of Work.
Stripping Away 'Proof of Work' Makes 'Collusion' a Much More Feasible Prospect
Notice how the chart / diagram above from the Elastos documentation fails to establish a cost that the network (and/or network players) must pay in order to validate the protocol.
Specifically, there is no ongoing cost that must be replicated - not just for a duplicate result - but rather to create an alternative result that could supersede the predominant established chain (i.e., the one with the greatest Proof of Work in the context of Bitcoin).
This is what protects Bitcoin.
Breaking it Down Further
If you're attempting to 'attack' the Bitcoin protocol, every means of doing so mandates that you provide a chain that possesses a greater Proof of Work than the currently accepted chain.
What This Means
The primary incentive to 'cheat' is to gain some sort of inherent advantage (in relation to one's competitors). However, if you're always forced to undergo the same manual labor that your peers must endure, regardless of whether you 'collude' or attempt to subvert things independently, then the incentive to cheat becomes 'null' because there essentially is no cheating - only 'front running'.
And, as we have seen time and time in the Western World's capitalist paragon, one does not need to necessarily "cheat" (in a literal sense) in order to ensure that they are the ultimate winners (i.e., we see alternatives manifest all the time via monopolistic domination of a given industry / oligopolies / violations of 'anti-trust' etc.)
This Highly Theoretical Model (Counterfactuals) Underpins the Failures of Plasma
For those that have been following Ethereum’s development, specifically its scaling proposals, you probably remember a time when there was a lot of discussion about something called ‘Plasma’.
What is Plasma?
“Plasma is a proposed framework for incentivized and enforced execution of smart contracts which is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide.”
So, essentially, Plasma is to Ethereum what Lightning Network would be to Bitcoin.
Without coincidence, the Plasma whitepaper was authored by Vitalik Buterin and Joseph Poon. If you remember when the Lightning Network whitepaper was referenced above, Joseph Poon was also listed as an author there as well.
Plasma 'Canned' Over Infeasibility
Undeniably, CoinTelegraph's journalistic integrity has suffered over the past few months, but one piece that it did publish recently that hits the nail on the head (in relation to 'Plasma') is this one here: https://cointelegraph.com/news/did-ethereum-silently-give-up-on-plasma
Gist of the CoinTelegraph Piece
In essence, the article covers Vitalik Buterin's gradual distancing from the 'Plasma' protocol he once fervently advocated for (at least Vlad Zamfir was smart enough to jump ship at the very beginning).
As many could have guessed, attempting to usurp a trustless protocol by introducing an "off-chain" settlement process will never amount to more than simply 'shaking hands' behind the scenes and "triple double swearing" that you won't "cheat" someone out of whatever agreement that's been ironed out - which is essentially antithetical to the innovation pioneered via the existence of Bitcoin.
Plasma and Lightning Network's Downfall: 'State Channels'
In a nutshell, state channels refer to what the Lightning Network seeks to implement on various chains.
It is explained (in its most primitive form), as the creation of an ‘off-chain’ transaction where two parties can interact with one another limitlessly without incurring any protocol-specific trading fees or having to wait until the transaction is confirmed.
When the two parties are done transacting with one another, they simply ‘publish’ the ‘state’ of the channel (i.e., the final balance) and then that final transaction balance is what is finalized on the blockchain.
Literal Translation of What is Happening in a State Channel
The underpinning of most ‘state channels’ (particularly Lightning Network) are multi-signature wallets.
What is a Multi-Signature Wallet?
So, you know how every transaction that you make on the Bitcoin protocol requires you to provide your private key as a ‘signature’ that proves that you’re the rightful owner of your bitcoins, correct? We no longer really see this in modern wallet interfaces, because it’s been dumbed down to let ‘non-tech’ people transact with one another — but this is literally how the protocol works.
Generally speaking, there is only one signature per public address on the protocol (we say public address and not wallet because wallets are not public keys but that’s a whole ‘nother story we’ll get to later one day).
So, a multi-signature wallet, on the other hand, is one where more than one private key is necessary to complete a transaction on the protocol.
This Medium article provides another thorough explanation of what these wallets are and how they work in relation to the Lightning Network protocol: https://medium.com/cryptoverze/what-is-bitcoin-lightning-network-and-how-does-it-work-cd80ba9c0bda
How Lightning Network Proposes to Function in Concert With Bitcoin Via 'State Channels'
It’s important to remember that you are technically not ‘off-chain’ in a literal sense — that would be impossible because blockchains are simply designed to account for the native asset in a tracked manner. Thus, there’s never a point in time when this is not happening.
So, when you enter into a ‘state channel’, the protocol perceives that as you moving your funds into another [multi-signature] wallet. It’s important to remember that the blockchain does not think about funds in terms of human-recognizable ownership. The only thing that matters in terms of ownership is who possesses the requisite private key(s) necessary to provide a signature for a transaction to be accepted and considered valid.
It is important to remember that moving one’s transactions ‘off-chain’ counts as a transaction on the protocol.
This is Where the Lightning Network Protocol Allegedly 'Saves' the Schema
Once in the ‘state channel’, the coins in that wallet are apportioned to the necessary wallets by the protocol (in this case, the Lightning Network).
To help explain this easier, let’s go with the classic Amy and Bob example:
Now let’s say Amy brought 5 bitcoins to the channel and Bob brought 3 bitcoins to the channel.
Let’s say Bob is selling some pizza and that pizza costs 1 Bitcoin (it’s the best pizza ever made in mankind).
Amy says, great Bob — this sounds like a deal.
Amy’s balance (in our heads) would be 4 $btc and Bob’s balance should reflect 4 $btc as well.
However, one must remember, the blockchain only sees this as one multi-signature channel — So, the semantic adjustment in balance for Amy and Bob has not been taken into account by the blockchain at this point.
In the blockchain’s eyes, this is still just a wallet that contains 8 bitcoins in it.
Below, is a more sophisticated diagram detailing the functionality of state channels:
Clearing Up a Misconception About State Channels; Pointing Out Numerous Limitations
Since there is no literal change in the balance, it is up to the users and the protocol itself (i.e., Lightning Network) to ensure that the balances are updated in the necessary manner via whatever ledger or balance of transfer that is being used in this case.
Since the state of the channel on the blockchain remains stagnant until a final status is ‘published’, and there are no miners on the secondary protocol (Lightning Network), it is up to the protocol to verify that the balances of the individuals within the protocol are legitimate.
For example, if for instance Amy tried to initiate another ‘transaction’ with Bob and claimed that she had her original 5 bitcoins at her disposal, rather than 4, it is up to the protocol or Bob / another 3rd party to ensure that the integrity of the channel’s state is maintained.
Inherent Shortcomings in the ‘Watchtower’ Proposal
In addition, Bob or Amy must remain online if they want to ensure that the channel is not published to the blockchain without their consent.
This has led some to propose a remedy where individuals can relegate the ‘monitoring’ of their blockchain to a 3rd party that will ensure that only the latest channel state is published to the blockchain.
But, what happens if the latest ‘state’ of the channel (again, not recognized by the blockchain but by the Lightning Network), is actually not accurate? Perhaps a vendor or a customer, under the pretense that the mutability of state channels guarantees that refunds will be honored, is counting on a former state of the channel to be published.
The 'Watchtower' Proposal Forces Blockchain Users to Rely on a Centralized, Ultimate 'Arbiter' to Settle Transactions and Determine Accurate Balances
What does that sound like?
Yeah, a shittier, non-FDIC secured version of a bank without the prestige, regulation / oversight, or accountability (for what little of that banks are forced to retain these days in a post-recession world).
Check out an outline of this 'Watchtower' proposal from Bitmex 'Research' below:
Let's annotate this audacious proposal for the modification of Bitcoin's network below:
Watchtowers Cannot Be Verified By Any Other Means Other Than the 'Watchtower'
The primary issue with these watchtower proposals is that if users rely on the ‘watchtower’ system (as some have named it), then they will be in some serious trouble, because there is no way to verify such an agreement.
Also, it’s worth noting that ‘watchtowers’ must be trusted entities.
It is proposed that a smart contract could be enacted in order to ensure that the ‘watchtowers’ or this third-party are compelled to ensure that the latest state of the state channel is published to the chain — but again, this would not only undermine the purpose of using a watchtower, it would also involve rigid coding language that would not allow for the reflexiveness that the Lightning Network advertises itself as having.
It’s also worth mentioning that these ‘watchtower’ entities will more than likely also mandate a fee for their services. Thus, the entire experience of creating a multi-sig wallet to act as a state channel, using an intermediary, and then publishing the final state of the channel itself will require at least 3 transactions on the main chain.
Thus, if the usage of the state channels does become widely used on a protocol that is already near the limit of its maximum throughput dictated by network conditions, then this could essentially stagnate the protocol in a further quagmire of immobility (in terms of transactions), or create an ever-increasing tailspin of fee hiking by those wishing to have their channels’ state published.
Another major issue for the LN = Lack of Robust Denial of Service Protections Conventionally Afforded by Blockchain for State Channels
Others have also noted the Lightning Network’s potential susceptibility to being pummeled with Sybil attacks.
Unlike the Bitcoin network or several other protocols (mainly ones that operate via Proof of Work), there is no inherent fee model to prevent nodes from attempting to connect with other individuals on the network.
Without an inherent disincentive to limit one from attempting to connect to as many peers as possible plus a method for restricting the name servers on the protocol (Lightning Network; i.e., one can register 10 different nodes under the name ‘Stellar’), the noted vulnerabilities on the protocol will continue to persist.
A recent research report that looks into the potential vulnerabilities that side channels possess to Sybil attacks can be found below:
This Vulnerability is Perpetuated By a Lack of 'Chain'
Ironically, for those that were complaining about the fixed size for acceptable blocks (i.e., data-wise), it turns out that this is the one saving grace that prevents rampant DDoS attacks (beyond what we've already seen on various blockchain networks at up to this point).
Because the 'block size limit' forces a competitive fee rate that is invariably correlated to the activity on the chain (i.e., the more transactions that need to be confirmed, the less available 'real estate' there is [if any at all], for those that wish to have their transactions confirmed).
However, since the protocol itself is asynchronous (i.e., not 'Proof of Stake'), there is a guarantee that there will be another block submitted / produced on the chain at some point as long as there is at leaset one participant on the network.
Thus, there is a perpetual and 'rolling' fee rate, contingent on the network's level of congestion at any given point of time.
And this would (obviously) not be possible without the existence of:
A) A block size limit (not praising it or condemning it - just sticking to the facts here)
B) An asynchronous protocol
C) Placing the decision to pay fees in the hands of those issuing the transactions (i.e., not the 'miners' themselves mandating it) - resulting in an organic increase
Vulnerability that 'HTLCs' (Hash-Time Locked Contracts) Creates on a Quasi/Pseudo-Decentralized Trustless Protocol
See the conclusion that researchers came to re: this structure as it relates to DDoS vulnerbailities below: