"A Lightning node cannot lose or run away with a user’s money."
That's just not true. Lightning is based on reactive security, where an attempt at taking a user's money is thwarted by a response. That response _can_ fail, and thus @coincenter's argument is invalid.
That's just not true. Lightning is based on reactive security, where an attempt at taking a user's money is thwarted by a response. That response _can_ fail, and thus @coincenter's argument is invalid.
What the Lightning protocol does is essentially it implements the regulatory punishments within the system: nodes can try to steal funds, but doing so is expected to be unprofitable, because the protocol allows for automatic punishment of theft.
In most circumstances Lightning punishments have a high probability of success.
But not all: a majority of miners _can_ censor Lightning punishment transactions, and thus steal funds. We should not underestimate that risk.
But not all: a majority of miners _can_ censor Lightning punishment transactions, and thus steal funds. We should not underestimate that risk.
Like it or not, an effective way to combat the risk of a majority of miners stealing funds from Lightning channels is to use semi-trusted Lightning nodes, that we know aren't colluding with miners.
We already trust Lightning nodes for privacy, so this isn't entirely novel.
We already trust Lightning nodes for privacy, so this isn't entirely novel.
An obvious thing to do is use SGX: have very long duration refund txs outside the enclave, with shorter durations stored within the enclave.
Unlike Teechan, this doesn't give the enclave the ability to directly steal funds, but does protect against miner-colluding theft.
Unlike Teechan, this doesn't give the enclave the ability to directly steal funds, but does protect against miner-colluding theft.
In Teechan, you literally gave your private keys to the other party! Emin appears to have done this to avoid segwit or previous payment channel tech, which he then lied by claiming it didn't exist.
By comparison to Lightning's reactive security, client-side validation can be passively secure, preventing theft 100% of the time while also scaling: lists.linuxfoundation.org/pipermail/bitc…
Different set of tradeoffs: trustless with respect to theft/validity, trusted with respect to censorship.
Different set of tradeoffs: trustless with respect to theft/validity, trusted with respect to censorship.
Bitcoin PoW is passively secure: after n confirmations, double-spending your coins requires the destruction of n blocks worth of energy, *regardless* of whether or not you take any actions. But it doesn't scale.
Lightning traded passive security for active security to scale.
Lightning traded passive security for active security to scale.
Mined sidechains are _always_ insecure for the same reason Lightning _can_ be insecure: while Lightning requires both the node and majority of miners to collude, funds on mined sidechains can always be stolen by a hashing power majority (and often by much less than a majority).
The best you can do with a mined sidechain is also reactive security: publish evidence on the main chain that the miners mining the sidechain had double-spent. Like Lightning, that's reactive security, and a majority of miners can censor that evidence and thus steal funds.
