Lightning Network must FAIL, if it succeeds

in #blockchain-scaling4 years ago (edited)

Transaction scaling is oft-touted as one of the prerequisites for enabling the future killer app(s)¹ of blockchains².

Even Jack Dorsey³ has (to put it politely) “naively” participated in the Lightning Network (LN) transaction scaling hype, and even adopted Bitcoin maximalism in the context of incorrectly¹ presuming that the killer app of Bitcoin will be as a transactional currency.

Ditto the proprietor of Theymos has “naively” participated in the shilling of the significantly limited MimbleWimble technology which the Grin altcoin is based on.

Tangentially Note: the above chart isn’t cited as an endorsement nor comparison of the security and any attributes other than transactions-per-second (TPS) of the listed distributed ledgers. For example, I wrote on Twitter, “XRP is a joke. None of the experts respect the algorithm […] Ripple is dog shit. I will cite myself as an expert on decentralized consensus ledgers.”

¹ The killer app of Bitcoin instead appears to be as the reserve (i.e. “hodler”) currency of cryptocurrencies, and possibly eventually the de facto international reserve asset— at least in the Internet and intangible goods economic sphere wherein gold is a useless ancient relic, especially within the context of the said sphere.

² Or more generally distributed (consensus) ledgers, including for example DAGs which have hash-chains but not blocks per se. Note the term ‘distributed’ is (not the same as decentralized and is) a superset of decentralized— i.e. most if not all extant distributed ledger protocols aren’t actually decentralized.

³ Jack Dorsey is the (co-)founder and CEO of both Twitter and the mobile payments app Square. Tangentially, his physical appearance IMO resembles a younger Mel Gibson.

Scalability Trilemma

Herds of gullible, self-important, wide-eyed “social consensus” believers (ostensibly including Jack Dorsey) lack sufficient understanding of some fundamental technological, game theory and economics facts. Facts which this blog post will attempt to summarize. These sheepeople fail to understand why and distinguish between that Bitcoin scales economically¹ but for reasons I will elaborate in this blog, secure transaction volume scaling is impossible (c.f. also) on any conceivable future variant of proof-of-work (PoW) which relies on transaction fees to fund the mining security.⁴

Additionally, all known, published extant distributed (consensus) ledger protocols — including² blockchains, DAGs, proof-of-stake (PoS) and PoW — lack at least one of the trinity in the impossibility theorem trilemma⁵: scalable, decentralized (aka trust-proof/trustless), and secure (aka consistent⁶).

Although this blog attempts to flatten my archives of prior analysis, readers are advised to click all my links and click all the links in the pages I’ve linked to (recursively) and read, read, read to gain more depth of understanding.

⁴ Transaction fees are necessary to fund mining if there’s a hard limit on the supply of tokens (e.g. 21 million for Bitcoin) so thus no perpetual minted block reward to fund mining. Yet extant PoW cryptocurrencies with a perpetual tail reward (e.g. Monero and Grin) either can’t scale transaction volume decentralized because some centralized lead developer or foundation has to periodically increase the block size (or in Monero’s case to set the minimum transaction fee) so that transaction fees don’t become too high (because unlimited block size results in transaction spam) and/or these anonymity altcoins (other than Zcash which has global mix set) must have a transaction fee to prevent spamming the mix sets and unmasking the anonymity (but hypothetically even that doesn’t prevent unmasking the anonymity if the mining is controlled by oligarchy which thus pays the transactions fees to itself). Note Monero is now also centralized in a futile attempt to prevent ASIC mining. Yet we can contemplate a future PoW altcoin which has a perpetual minted block reward, a Zcash-like global mix set, and which employs recursive zk-snarks or zk-starks to achieve unlimited on-chain transaction scaling without needing any transaction fees! The computational requirements of the zk-s(n|t)arks prover algorithm becomes the de facto transaction cost. Yet such altcoin design wouldn’t have the status as the absolutely best store-of-value because of the perpetual debasement of the token supply. And because the design wouldn’t have the highest difficulty chain (aka longest chain) since it wouldn’t extract the maximum fees the market can bear, and so thus it wouldn’t have the security and immutable Nash Equilibrium of “The One Chain to Rule Them All” which is only (the Real, original, immutable not Core) Bitcoin.

⁵ Impossibility theorem trilemmas are common in economics, natural sciences, and computer science, e.g. Brewer’s CAP theorem, Zooko’s triangle, tracing GC’s “Three-Legged Stool” (c.f. also) and unanimity+independence+consistency in social consensus .

⁶ Note security may be dependent on decentralization such as for avoiding 50+% attacks, yet a ledger protocol (such as the original “block lattice” protocol proposed for RaiBlocks) could be decentralized but inconsistent and thus insecure.

Transaction Fees Tragedy-of-the-Commons

Before I explain why LN (and any possible future off-chain scaling variant for proof-of-work) is fundamentally and unfixably flawed, I must first explain why on-chain transaction scaling isn’t possible for any extant nor conceivable future variant of PoW.

The unavoidable invariant is that PoW requires significant funding for miners in order to bolster the security of the longest chain against rented hashrate attacks. The $multimillion Bitcoin Gold 51% attack eight months ago and Ethereum Classic’s recent 51% attack highlights the critical importance of funding security adequately.

@Noah Ruderman wrote:

It’s an economic reality that the value of the transactions must at a minimum exceed the transaction fees paid.

Inability of:

  • a decentralized, free-market protocol to scale transaction capacity, so as to prevent fees incessantly rising as transaction volume does
  • while not simultaneously driving fees to 0, thus enabling transaction spam and depriving miners of sufficient revenue to adequately secure the ledger (such as against rented hashrate attacks)

Is the elephant-in-the-room stumbling block precluding decentralized transaction scaling, notwithstanding also the necessity of scalable throughput and acceptable transaction latency.

As early as 2013 (c.f. my comment on ESR’s blog, Spiraling Transaction Fees, Will Bitcoin Suffer a Mining Tragedy of the Commons and How can market-based transaction fees scale?), I had alluded to lack of non-monopolized, free market-based transaction fees being the Achilles heel of all extant distributed (i.e. erroneously claimed to be decentralized) consensus ledger systems.

There’s an unfixable and unavoidable economics and game theory dilemma in any conceivable variant of PoW, even if it eventually becomes possible in some future protocol design to solve other security and decentralization flaws that I pointed out for various technological attempts for achieving sharding in proof-of-work. Said already analyzed flawed attempts included so far for example QuarkChain, OmniLedger, Elastico, Facebook’s Chainspace, and proof-of-collaborative-work.

Succinctly that dilemma is that unbounded on-chain transaction capacity (i.e. effectively unbounded block size via any means such as sharding) destroys the transaction fee market (i.e. transaction fees drop to near 0 due to unbounded supply) which (as the minted block mining reward necessarily⁷ declines towards 0) is required to fund the security of a PoW or PoS ledger. Even if it’s dubiously argued that a small ongoing money supply inflation can provide enough security, transaction spam due to 0 fees given an unbounded capacity can also wreck havoc in other ways, such as for example providing a means to flood and deanonymize Monero’s Ring signatures. Monero’s adaptive block size protocol doesn’t prevent the destruction of the transaction fee market because without the minimum transaction fee periodically adjusted by centralized control (the same @fluffypony centralized control that is recently changing the PoW every ~6 months in a futile attempt to defeat ASICs) promotes the block size to increase so that transaction fees decline to ~0 (i.e. to miners’ negligible incremental costs for adding additional transactions).

Whereas, a transaction capacity bound (aka block size limit) has to be immutable otherwise the “social consensus” involved to change it would (as democracy and voting always does) steal, squander, and destroy all the value. There’s no Nash Equilibrium nor Schelling point if every possible value for the block size is on the table to be fought over (c.f. in the footnote “¹” at the linked post, my point to @dinofelis about the Nash equilibrium Schelling point). For example, we can envision scenarios such as by politicians representing competing forks offering some benefits such as tokens to everyone who votes to inflate the money supply. Well we don’t need to envision because it’s already occurred in our cryptocosm. Doesn’t that resemble what has actually been happening with the ongoing forkathon Scalepocalyspe:

⁷ The minting of new tokens for miner rewards in every new block must eventually decline to ≈0, so token money supply is effectively capped (e.g. 21 million Bitcoins) even if that supply continues to grow too slowly to be of concern (in Bitcoin’s case for ≈136 years). Bitcoin’s and Monero’s minuscule tail reward isn’t likely an exception to the stated dilemma.

⁸ Which is still running and will reassert its dominance over Core eventually because it will be so lucrative for the miners to do so.

Immutable Bitcoin Survives Destructive Politicized “Societalcide”

Once the democracy camel gets its nose under the edge of the tent, the tent is doomed to eventually come toppling down. Over the next decade or so, it will eventually become evident that Satoshi’s immutable Bitcoin protocol is going to rein⁸ in a scorched earth outcome for non-meritocracy, as Western democracy has bankrupted itself into a coming economic abyss and is sliding towards a messy clusterfuck of politicized “social justice” civil war “societalcide” (fomenting already as the Yellow Vests rebellions coming eventually also to the USA).

Tangentially note, I’m bullish on the meritorious factions of the global economy going forward— i.e. those people who wake up and understand what this juncture in human history entails. Who thus abandon all the incorrect non-meritorious concepts such ass democracy and “social consensus” blockchains, and embrace immutable Bitcoin and other meritorious innovations that may be coming. Jack Dorsey is likely one of those buffoons high on the “social justice” drug, who will be swept away as they fu*k off from immutable Real Bitcoin to numerous seductive Bitco[i]n impostors (as analogously Mel Gibson³ was by apparently seduced by cocaine) because they’re incapable of comprehending what is really going on.

Even Nick Szabo has concurred that Lightning Networks isn’t socially scalable because it’s not trustless (aka trustproof).

Lightning Network Can’t Scale Securely

This section also applies to other off-chain payment channel network (PCN) designs such as Ethereum’s Raiden Network.

Each user (i.e. payee) that received any incoming funds via a PCN’s off-chain transactions must periodically issue an on-chain transaction so as to close their channel before it expires. Otherwise the channel’s expiration refunds the funds to payer. In addition to other flaws, this design incentivizes delegation to Mt. Box “watchtowers” which (even if block size could somehow scale without centralized control over periodic block size increases or otherwise without a transaction fee market tragedy-of-the-commons) obviate any claims for anonymity/privacy, in addition to the ultimate result of an insecure fractional reserves system due to the spiraling transaction fees because of the (need to avoid the) transaction fee market tragedy-of-the-commons as explained below.

It’s not possible to provide unbounded off-chain scaling by keeping channels opened essentially indefinitely by setting the expiry too far into the future. Because the users would need to close their channels (after not an egregious delay) if the counter-party (to either of the two parties in the bidirectional channels) became unresponsive, uncooperative or poorly routed. If the counter-party won’t ever sign another multisig transaction after the opening on-chain transaction which sets the expiry, then the afflicted party has their funds locked up until expiration. The refund transaction can’t be accepted on-chain until expiry, because the channel protocol would otherwise be insecure (as well be explained in the final section of this blog).

(Tangentially note this is the reason that both parties should provide equal funding to the channel so they both have equal funds locked up by such a liveness attack, even if it’s expected that the flow of funds won’t be bidirectional. Otherwise spamming with liveness attacks would be free and unlimited.)

Thus although LN can compress many off-chain transactions into a fewer number of on-chain transactions, LN can’t remove the requirement for users to frequently issue on-chain transactions. This is a critical, unfixable flaw in LN.

The problem remember from the prior section is that whatever block size (or more generally speaking, the on-chain transaction capacity limit) chosen, it must be immutable else as I explained in the prior section, the Nash Equilibrium that gives Bitcoin its value is lost. Eventually the chosen immutable block size (aka on-chain transaction capacity limit) will be exceeded by on-chain transaction demand and incessantly drive transaction fees higher until eventually transaction fees will be too high for most people to even afford to issue a transaction to open and close a channel on-chain. The transaction fee will greater than their Bitcoin balance.

We could contemplate a design employing Schnorr multisignatures to compress all the multisigs into one signature on-chain, and even forming multi-way channels amongst more than two parties in order to reduce on-chain transactions by significantly greater multiples. Whether this would be secure and robust is irrelevant, because the channel settlement or expiry refund transaction which closes the channel must pay to (and thus include) the public addresses of all parties. So it’s compression instead of unbounded capacity and thus it wouldn’t alleviate the ramifications of the aforementioned flaw.

As explained above, the flaw isn’t even about any particular block size compression level, no matter how wonderful the compression might be, because eventually transaction demand will far exceed any chosen immutable level of block size or on-chain transaction capacity limit. And even more saliently is that the “Mt. Box” entities will always be able to provide lower-costs to fractional reserve accounts and IoT will for example demand trillions more transactions than human directed payments and at minimized costs. So “Mt. Box” controlled channels will be able to pay much higher transaction fees than individual-controlled channels, thus crowding out and kicking the masses off-chain to fractional reserves. This is just a fundamental physics and economics lesson about the power-law distribution that dictates resource allocation.

Incidentally, this Layer 3 design has already been proposed (Edit: and it’s apparently been named channel factories), but the touted compression isn’t going to be achieved (which per the prior paragraph wouldn’t resolve the fundamental flaw unless the achievable compression was unbounded which obviously it can’t possibly be in practice⁹) because the realtime coordination of such large groups will be unrealistic⁹ unless users delegate their private keys to “Mt. Box” entities in which case that’s fractional reserves and because (as the linked paper admits) the compression is reduced at asymmetrically lower cost to an adversary that intentionally becomes unresponsive. “Mt. Box” entities and competing altcoins would have an incentive to surreptitiously/anonymously attack in order to force channel users to instead use fractional reserves as described below. Asymmetrically low attack costs are the hallmark of a vulnerable system because honest users are incurring relatively more cost than the attacker. Another source of asymmetry in this attack (where the adversary utilizes the channel for sufficient time to recover costs of the attack before becoming unresponsive) or in general is that those with more reliably frequent transaction activity (e.g. “Mt. Box” entities) receive more value out of the channel. I could elaborate because I contemplate more vulnerabilities than holes in Swiss cheese, but that’s enough writing on Layer 3 proposals for now.

⁹ Users have varying reliability of connectivity. If even one user in a multiparty (i.e. especially a Layer 3 “channel-factories”) channel becomes unresponsive for too long (e.g. network hiccup), the responding channel members incur the cost of either waiting (potentially for nothing because it’s unknowable if the non-response is due to an attacker or the user being indefinitely offline) or the cost of resetting the channel with the faulty user removed. Thus the viability of the protocol declines as the channel group size increases. Thus it’s not plausible for it to be unbounded in the compression of on-chain transactions (and thus can’t solve the fundamental flaw that transaction fees will eventually become too high for users to issue the necessary on-chain transactions). Note that the unbounded contemplated in this context is applying to the ratio of off-chain transactions possible per on-chain transaction so it wouldn’t destroy the transaction fee market for on-chain transactions (because it wouldn’t make on-chain transaction capacity unbounded) if it were even possible. But the unbounded compression (of ratio of on-chain to off-chain transactions) due to Layer 3 isn’t possible for the reasons articulated.

Tangentially Note: We could instead contemplate a design employing on-chain hashes (or analogously Schnorr compression) to represent what would have otherwise been placed into the limited block size (essentially SegWit’s compression scheme applied more aggressively), but as contemplated this would be equivalent to an unbounded on-chain transaction capacity limit (i.e. it’s on-chain because miners would have to verify what the hashed data represents to prevent double-spends, etc) that in theory it would as explained in the prior section destroy the transaction fee market and drive miner revenue to ≈0. But note analogously as for Grin/MimbleWimble (c.f. “Tangentially Note”) that this contemplated design wouldn’t actually achieve unbounded transaction scaling.

I wrote on Medium 8 months ago:

[Transaction] Scalability is the ability to continue [transaction] scaling proportional to the number of nodes added, so that it has no upper bound. For example demand, IoT may require billions or trillions of transactions per second. Lightning Networks (LN) is not on-chain scalability. I am writing about on-chain [transaction] scalability […] Proportional optimizations[compression] do[es] not provide scalability in a mathematical sense […] That is not a correct definition of scalability from a mathematical context such as complexity theory […] Proportional optimization doesn’t change the constant (e.g. O(1)), logarithmic (e.g. O(n log n)), polynomial, subexponential, or exponential curve of the complexity invariant of the scalability model.

Thus as users eventually get kicked off-chain by exorbitant transaction fees due to the immutable block size required by a Nash Equilibrium, LN necessarily ends up as the masses holding their balances off-chain with “Mt. Box” entities instead of on-chain. The “Mt. Box” entities will be forced to aggregate the users’ transactions on a much fewer number of channel(s) with large committed balances controlled by said “Mt. Box” entities instead of each user signing the on-chain multisig transactions. This is analogous to users holding balances at centralized exchanges. Invariably such centralized exchanges are losing/stealing the actual Bitcoins and the users eventually end up losing all their Bitcoins. And thus the “Mt. Box” allusion to the Mt. Gox theft fiasco that precipitated a 3-year crypto winter and 87% crash of the Bitcoin price in 2014.

The relevant analogy are the bank runs of the 1800s (c.f. also) when the USA was dominated by banks issuing IOUs (which traded as currency) for physical gold held at vaults. Any hint of insolvency would cause a bank run and the bank would be quickly insolvent if it didn’t have enough physical gold to fund all the deposit accounts. Fractional reserves would persist for a long-time before each bank run, because this was a lucrative confidence game for the proprietors of banks. The distributed confidence problem was eventually “solved” by creating a “too big to fail” system (until the entire Western society implodes as explained in the prior section) by backing the banks with the full faith and credit of the USA Federal government under the legislation that created the Federal Reserve in 1913 (c.f. also). And eventually systemic failure caused the USA to leave the gold standard and back the reserves with nothing but the confidence in the ability to print dollars out-of-thin-air with that confidence implicitly backed by the value of economy that runs on the dollar. Problem is that Bitcoin is analogous to gold and can’t be printed out-of-thin-air to sustain confidence in leverage and at this juncture in human history (with the Grim Reaper coming soon for Western society and democracy) within a decade no nation-state’s credit will be trusted more than hodling Bitcoin itself.

So while LN might initially grow in popularity and adoption, it will eventually become clear that it’s a mess analogous to the mess of the 1800s when the USA seemed to have an economic depression every other decade due to the instability of the banking system. In this digital age, time frames are compressed (because communication and change travels instantly). So if LN becomes significantly adopted, we can expect a crypto winter depression due to LN chaos much sooner than every other decade.

Lightning Networks vs. Vaporware Hypothetical Decentralized Transaction Scalability Altcoin

Why would the people of the world want to continue (after such mess becomes evident when/if LN has gained significant enough adoption) hodling an asset and using it as a currency which is so fraught with loss of funds and systemic failure risks (such as crashing the Bitcoin price)? Especially this will be true if they have safer and equivalently permissionless alternatives (such as perhaps superior altcoin designs).

Additionally LN (and HTLC in general) only scale bidirectional payments (or changes in state confined to a small grouping) and thus can’t ever (in any conceivable protocol design) work for generalized distributed ledger updates such as I have proposed for decentralizing all the centralized databases and behemoth Internet sites. Thus how will LN be more popular than an altcoin which provides these generalized distributed ledger features at-scale, so as to drive mass onboarding and adoption of transactional cryptocurrency and decentralized ledgers.

Given that LN is a technology added to Bitcoin (and other altcoins but not itself a tokenized altcoin that can be invested in by adopting and using it), it also lacks any FOMO “pump-amentals” — which are the hallmark of Fat Protocol altcoins — to drive its onboarding and adoption. The hen-egg onboarding problem that has plagued Bitcoin adoption as a transactional currency remains, in that the masses won’t spend their money to buy Bitcoin to experiment with an inferior payment system that has no economies-of-scale.

The technologically ignorant argument is that users will demand to pay denominated in Bitcoin via LN for the said hypothetical generalized distributed ledger features at-scale. But there’s no plausible technological way to securely prove in real-time the non-existent clearing (which won’t occur until the channel is closed) of such off-chain payments as recorded on the distributed ledger that provides the said features. Without going into too much technobabble detail, the summary is that there’s no plausible technological way to cross-integrate the LN off-chain payments with said external vaporware altcoin(s) with low-latency distributed ledger(s).

Lightning Network Explained

This section is intended to be a very terse, simplified explanation without any graphics. So some readers may wish to also consult other explanations on the Internet.

LN is composed of two-party, bidirectional, off-chain transaction channels. The two parties open the channel by both signing an on-chain multisig transaction which locks up the each party’s funds until the channel is closed. Both parties also sign a refund transaction which undoes all the activity of the channel, but this refund transaction has a lock time so it can’t be accepted on-chain until the channel expiration time.

Any portion of the funds in the channel can only be sent bidirectionally to either party in the channel by agreement of both said parties. When the parties want to send funds between each other (in either direction), they both must sign a new multisig transaction with the outputs being their new agreed balances. They don’t send the transaction to the blockchain unless they want to close the channel. When either party wants to close the channel, either party may post the latest said transaction on-chain before the channel expiry.

One attack vector is neither party is able to post the most recent transaction on-chain before the channel expiry refunds all the channel activity. Conceptually and hypothetically another attack vector would be if either party posts the not most recent transaction on-chain (which thus refunds all the activity in the channel that followed that not most recent transaction). One way to resolve this would be the other party can still recover by posting the lineage of channel activity transactions that had followed. But this increases the on-chain transaction volume. Thus in order to minimize on-chain transactions that would need to sent in such an attack, a sane protocol would require every new transaction created in the channel activity, must also include both parties signing a separate direct transaction from every prior transaction in the channel to the most recent balance of funds. But LN actually employs a different protocol which gives each transaction a lower expiry time. (Edit: apparently SIGHASH_NOINPUT is another proposed mechanism for efficient handling of adversaries who attempt to publish incorrect channel state.)

These two-party, bidirectional channels can then be utilized to forward payments through them as intermediary channels (chained together to reach any party that can be routed to) via the clever use of Hash Time Locked Contracts (HTLCs) to provide a scheme to allow atomic transfer over a chain of multiple channels. Essentially this is a “pay to hash” and each payer in the chain not releasing the hash preimage secret until all downstream intermediary parties have correctly signed. Another problem is that this routing doesn’t scale without large “Mt.Box” intermediaries. And I also explained in a prior section why these “Mt.Box” aggregators will also be naturally incentivized by the rising on-chain transaction fees.

ChangeTip Died

Well I see Jack Dorsey continues his naivete, now endorsing tipping on his Twitter, which has already been tried (numerous times) and failed for well understood economics of bundling and cognitive load of tipping. Also there’s the hen-egg onboarding problem that people aren’t going to go buy Bitcoin just so they can send tips.


this is the input I´ve missed on Steem(it).

its like searching for a better version of the wheel. One can add technologies around the wheel (high tech tires, sensors) but one cant improve the concept 'wheel' ("On-wheel"-implications introduce fragility).

Peter R. Rizun, Chief Scientist at Bitcoin Unlimited, is receiving significant publicity (c.f. also) for identifying the flaw in Lightning Networks (LN) that it will be unable to securely process transactions that are less than the on-chain transaction fees.

I wrote in a comment on Peter’s blog:

Peter, thanks for popularizing my long-standing criticism of LN. For example, on Feb 9 (a month before you wrote this blog), I wrote in my blog “Lightning Network must FAIL, if it succeeds”:

The problem remember from the prior section is that whatever block size (or more generally speaking, the on-chain transaction capacity limit) chosen, it must be immutable else as I explained in the prior section, the Nash Equilibrium that gives Bitcoin its value is lost. Eventually the chosen immutable block size (aka on-chain transaction capacity limit) will be exceeded by on-chain transaction demand and incessantly drive transaction fees higher until eventually transaction fees will be too high for most people to even afford to issue a transaction to open and close a channel on-chain. The transaction fee will greater than their Bitcoin balance.

Note I have refuted the “Probabilistic Payments” proposal. And I refuted Gregory Maxwell’s claim that the game theory disincentivizes the thefts.

Here is the content of above mentioned “Probabilistic Payments” refutation:

Probabilistic payments won’t work for the same math reason that non-pooled mining doesn’t work— variance. Users could be waiting weeks, months, and eventually years to ever get paid anything. Especially given BTC is going to $1 million within 4 years. Peter Rizun is repeating a long-standing criticism I have made against LN.

To unpack that more, note that if ratio of the LN payment amount to the minimum on-chain transaction fee becomes very large (e.g. 10,000+) then the variance in terms of number of payments required before the payee receives anything can be quite high.

Also here’s the content of the refutation of Gregory Maxwell:

and an attaker would have to burn quite a bit more in fees to trigger it

Incorrect. The losing routing party also loses more on-chain fees than the value of the micropayment lost if they decide to close the channel. Also given the need for channel liquidity, the little guys just have to eat these thefts as a cost of being accepted to channel with a Mt. Box node. Given the microtxn is hidden in the fee, there’s no way to even objectively prove malfeasance.

Essentially AFAICS there’s no incentives compatibility at all for transactions valued at less than (or even slightly greater than) the on-chain transaction fees involved with opening and closing the channel. Because neither counterparty to the channel has an incentive to lose those fees (to penalize their counterparty for malfeasance) and incur more fees to open a replacement channel.

To unpack that more, the attacker has to spend fees to open a channel on-chain. Ditto the counterparty to the channel. If the attacker doesn’t credit funds that were hidden in the fee, both the attacker and the counterparty would lose a larger amount than the theft if their channel is closed on-chain. So neither have an incentive to close the channel. Also the counterparty to a Mt. Box node needs the liquidity of that Mt. Box node, so will not gain anything and will actually lose more by attempting to penalize the attacker.

Thanks for the great input!

Posted using Partiko Android

I am innately hostile to PoW. I do appreciate being so thoroughly confused though.


Congratulations @anonymint! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :

You got more than 4750 replies. Your next target is to reach 5000 replies.

Click here to view your Board
If you no longer want to receive notifications, reply to this comment with the word STOP

Do not miss the last post from @steemitboard:

Valentine challenge - Love is in the air!

Support SteemitBoard's project! Vote for its witness and get one more award!

Coin Marketplace

STEEM 0.22
TRX 0.06
JST 0.025
BTC 19571.90
ETH 1321.67
USDT 1.00
SBD 2.44