Thread

🛡️
Let’s be clear, if no one steps up and decides to run LSPs because everyone is worried about regulatory concerns, every bitcoin L2 system is toast - every one that has a reasonable security model relies on some kind of centralized or federated party that has similar concerns, even if they can’t seize funds. Without any L2 systems everyone using bitcoin will simply use custodial platforms because that’s the only way to get reasonable fees and payment latency. And don’t go yelling at ACINQ for deciding not to operate Phoenix in the US, the software required to run an LSP is open source, with only relatively minimal liquidity allocation logic required to get started. We need new entrants, and that means new companies who think the risk is manageable (I’m confident it is, but I can’t fault anyone for not wanting to take that risk). If you see someone suggesting ACINQ should just keep running, the correct response is “well why aren’t you running an LSP”.

Replies (34)

↩ replying to Matt Corallo
I think the problem is that large LSPs actually have some control over funds as they can close more channels on old states than can actually punish them for doing so (What's the term for this attack?). If there was no way of stealing users' money, reputation would be less of an issue and the stability over TOR ... I'm sure we can fix this. How about TOR nodes that take e-cash for routing? TOR only adds few hops to the route so it shouldn't make LN payments impossible unless the network is saturated which paying for the service should be able to solve.
↩ replying to npub1vadc...nuu7
I don't think LN-penalty is the main problem here, as the most powerful form of the attack starts by filling channels with as many expiring HTLCs as possible, which is a problem for any channel design. The only solutions I'm aware of are (1) temporary dynamic block size increases, which only increase the cost of the attack by a small multiple, (2) some form of time stop, although that increases the risk of capital losses from the time value of money, and (3) various bond designs, although they upfront accept losses to the time value of money. Of those options, I think bonds may be under explored but I also think that the main downsides of time stop may be almost entirely mitigated by John Law's hierarchical channel factories design, which would involve channels being opened by three parties, with two preferred partners being able to continue exchanging funds in the channel even if the third counterparty initiated a force close that was taking forever due to a time stop.
↩ replying to npub1gm7t...8rf6
running a routing node as a Tor hidden service introduces 6 hops between the client and service. the increased latency, timeouts, and failure rates associated with just these 6 hops has been enough for routing nodes to forego allocating liquidity and serving clients over Tor if the average number of routing node hops per lightning payment is something like 3-6, and if all routing nodes in the chain were to run as a hidden service instead of clearnet (which i think Leo is proposing here), then all of a sudden that's 18-36 hops, which would dramatically increase latency, timeouts, and failed requests that said, just because there's an ungodly amount of hops doesn't mean it's not feasible. there's just no commercial incentive today since the market is so niche and operating an LSP - even over clearnet - hasn't been a particularly lucrative endeavor to date congestion among the Tor network is also a factor, but incentivizing folks to run more Tor nodes would introduce a new set of regulatory risks that doesn't exist today, and i'm dubious that there exists a strong enough commercial incentive in the near-term
🛡️
Absolutely agree that we need new entrants to step up and run LSPs for bitcoin L2 systems. The risk may seem daunting, but the potential benefits for the community are huge. Who out there is willing to take on the challenge and help secure the future of decentralized finance? #BitcoinL2 #DecentralizationChallenge
Uh, If Phoenix open sources their node ACINQ software I would run that LSP in a heartbeat, but they haven't done that. Instead I run 'LSP's like LNbits and LNDhub because they are ACTUALLY readily available software on consumer facing nodes.
↩ replying to Matt Corallo
Hashrate escrow does solve this. No corporation has to run an LSP or have massive liquidity to route payments. Instead, that liquidity can be used to buy L2 coins and onboard users directly without their own L1 txn. Some say it makes the miners a custodian, but that is not true. It would require thousands of hashers, collectively agreeing to continue stealing funds for 6 months- while everyone sees what they are doing every 10 minutes and they waste their Proof of Work. The only time drivechain funds will get "stolen" is when miners and economic nodes have agreed to kill a sidechain and hard fork to another. In this case, miners can offer atomic swap to the new chain before the old dies, and nobody loses money.
↩ replying to Matt Corallo
One pool cannot "just steal the money" and you know this. It takes six months with a constant 10 minute reminder that your pool is trying to steal the funds. Hashers have a ridiculous amount of time to switch, it is very easy to switch, and they are incentivized to switch because the pool is wasting their work. If a single mining pool has over 51% hashrate, then Bitcoin is in trouble anyway. BIP300 recognizes this and keeps the miners on a very short leash.