# WEEK 4 - LIGHTNING SEMINARS - LIMITATIONS
## Lightning Network 2.0
### Problem 1: Liquidity
If our friend Alice wants to pay 1 BTC to Bob, it isn’t enough for Alice to simply find a route of channels between herself and Bob; she must find a route in which each channel hop has at least 1 BTC available in the direction her payment is to travel.

The easiest way for me to maximize my access to the network is to connect with a node that already has many channels; thus, the nodes with the most channels may be natural attractors for even more channels (I propose that we call them “lightning rods.”) This could lead to a “hub and spoke” topology, in which a select few large hubs maintain the majority of channel traffic.

#### Atomic Multipath Payments
Suppose dear Alice wants to pay Bob 1 BTC, but no path exists between Alice and Bob with 1 BTC staked each step of the way. However, Alice, clever lightning router she is, does find one path where she can send Bob 0.5 BTC, another path for 0.3 BTC, and another for 0.2 BTC. With an Atomic Multipath Payment (AMP), Alice can pay Bob by splitting her payment into these three (or more, in theory) parts.

### Splicing
Splicing opens up the door for this, enabled by an alternative state-channel transaction structure called “FundCasc.” In this arrangement, funding transactions can take an arbitrary number of inputs and outputs, including — crucially — other funding transactions. So under the hood, “splicing in” (adding funds to a channel) simply entails closing out one channel and opening up a new one in a single transaction. This new channel takes as inputs the old channel (and thus the old stack of commitment transactions are invalid, so we don’t have to worry about them) along with some other, on-chain BTC. The net result being that the two counterparties still have a channel open together, only now the available funds in the channel have increased. Splicing out follows similar logic; a single transaction closes a channel and spends its funds in the form of two new outputs: one output lives outside of the LN, the other establishes a new channel with the remaining BTC.
Just to underscore a point: splicing in and out does require one on-chain transaction, putting an upper bound on how much this technique could and should be relied on.

### Problem 2: Liveness
### Submarine Swaps
The idea of submarine swaps is to help bridge the divide between on-chain and off-chain funds; with a submarine swap, Alice can pay Bob by sending him an on-chain transaction, which Bob effectively receives as a payment in one of his already existing state channels; conversely, Bob can pay Alice by sending a lightning payment that Alice ends up receiving as on-chain BTC. There are a number of potentially valuable use-cases for this mechanism, the most obvious being helping Bitcoin through its transition phase to more LN adoption, when some — but only some — users have taken to using lightning.

### Compact Block Filters for SPV clients
A different type of light client can accomplish exactly this, using compact block filters. The idea here is that full nodes expose a “filtered” block to any listening light client; now, instead of a light client requesting data for relevant transactions, the client can examines the filter and probabilistically determine whether their transaction-in-question could be included. The key here is that the client cannot get any false negatives; the data structure is such that the answer is either “your transaction is definitely not in this block” (this will be the answer most of the time) or “your transaction might be in this block.” In the later case, the client can then simply request the full block in question, verify it against their own block headers, and then act accordingly.

Net result: self-verification that all channels are still open, no full node required.

### Eltoo
Eltoo is yet another trustless, multi-party state channel mechanism (that makes three) that mitigates this particular risk. This time, the answer to the canonical “what happens when outdated transactions get broadcast” question is “those transactions will be considered perfectly valid, but any later transaction from the channel will then be able to replace it.”

Beyond just mitigating the risk of punishing an innocent actor, Eltoo has an added bonus: thanks to the SIGHASH_NOINPUT flag, update transactions behave as “floating transactions,” meaning they can be used to nullify any attempted settlement with a lower sequence number than their own. Thus, the only pieces of data that a party needs to hold on to are the latest update and settlement transactions; compare to Vanilla LN channels, in which a revocation transaction needs to kept for each commitment. This means easier, simpler state management for everyone.

### Problem 3: Routing
A state-snapshot of the LN essentially comes down to four dynamic variables:
Existence of channels
Amount of funding in channels
Routing fees
Liveness of nodes
Of these, one could reasonably expect that 2–4 would be changing very rapidly, whereas the existence of a channel itself would alter comparatively rarely. Thus, the strategy for maintaining network state is to keep channel existence up to date proactively; in other words, a node, for all intents and purposes, knows the state of all of the channels it cares about at all times. Alternatively, the information in 2–4 is obtained reactively; only when a node is making or receiving a payment does it bother digging in to find it; it’s strictly a “need to know” basis.

Using this hybrid strategy, each node constructs its own routing table which stores paths of nodes within that node’s neighborhood, a neighborhood being all of the nodes that are within n channel-hops away. Additionally, each node has a randomly selected group of beacon nodes. These beacon nodes are simply other nodes in LN from which a node uses to get a random snapshot of data about sections of the network outside of its neighborhood. When Alice and Bob wish to find a route between them, they check for overlaps in their own neighborhoods, then check for overlaps among the collective nodes they have access to via their beacons, and finally, if necessary, start polling their peers for additional data until a path is found.

## Lightning Limitations
- cannot do rare, random, high value transfers
- run nodes
- a decentralized layr 1 is necessary
- "broadband" requires both sides have good connectivity - last mile problem

Competitors: Blockchain - good for:
- less repetition
- higher value
- colder funds
- lightnin scales by shifting responsivility to users

Custodial vs Lightning
- cant do small values on blockchain
- you can do anything with custodial solutions
- lightning requires more responsibility

### Block Size Limit
how many channels can we fit on a blockchain
Reduce the size of channels:
- vByte Saving tricks
- reduce outputs by rebalancing before closing
- open and close a channel in the same tx
- change N:N sigs into 1 sig with sig aggregation
- lower chain impact by cooperatively closing
- trim outputs into miner fees, if close uncooperatiley
- having more members in a channel
- each member needs an additional output
- only 1:N funders is necessary

- responsibilites
- who owns what funds
- who checks updates
- how do we sync the network info to people

- shard responsibility
- you are responsibile fofr the db of your own funds
- only present minimal aggregated proofs
- only validate the people you interact with

- capital limits
- at small values, chain settlement isnt realistic
- only medium values are ok

- multiple payments path
- base AMP: wait around for the full amount
- link AMP: make it worth my while to complete a forward
- OG AMP: shard secrets, ideally leveraging schnorr

- multiple system support
- submarine swaps

- protocol limits
- dynamic remote addresses
- unadjustable csv fees
- channel capacity amounts are fixed, limited
- funding tx cannot be fee bumped
- you cannot push a payment

### Spamming the Lightning Network
An evil routing node can use this property to ensure that its competitors' channels are unable to route payments: this may force payers to route through the evil node's channels instead, earning him fees and potentially making it economically unsustainable for his competitors. An even more evil entity could make the whole public lightning network unusable if it has access to a fraction of the network's capacity.

## What variables other than htlc_min_val and max_num_htlcs could be tweaked to make it harder or less attractive for an attacker to try and lock up a channel?
* **Increasing pending HTLC default value per channel:** Since payment routes can be at most 20 hops, it looks like the attacker can lock 20 times the funds he's allocating to the attack. But in reality it's worse: there is a limit to the number of pending HTLCs a channel can have (by default 483 HTLCs). By completely filling a channel with tiny HTLCs (just above the dust limit) the attacker is able to lock the whole channel down at a very small cost.

why 483

* **Increasing Dust Limit** By completely filling a channel with tiny HTLCs (just above the dust limit) the attacker is able to lock the whole channel down at a very small cost.

- `htlc_minimum_msat`: the attacker needs to lock at least `htlc_minimum_msat * max_accepted_htlcs` of his own funds to completely fill a channel, so you should use a reasonable value for htlc_minimum_msat (1 sat is not a reasonable value for channels with a big capacity; it may be ok for smaller channels though)

- open redundant unannounced channels to your most profitable peers
- not possible in clightning but yes in lnd
- better for trusted peers only
- implement relaying policies to avoid filling up channels: always keep X% of your HTLC slots available, reserved for high-value HTLCs
https://api.lightning.community/#htlcinterceptor

- spamming with similar path

- if your peers implement same good spamming strategies

Long-lived controlled spams might also be mitigated by a relay policy rejecting too far in the future CLTV locktime or requiring a lower `cltv_expiry_delta`. This later mitigation may downgrade relay node security.

 // The time-lock delta of the channel.
    uint32 cltv_expiry_delta = 5;