No, LDK is much more 'DIY' and doesnt include common default params

There are a few assumptions that went into this paper to arrive at a rough ~750BTC number - the 'vulnerability' can be better described as an attack vector to steal sats from unwitting node ops. I'll try to boil it down

1. First, a threat actor needs to own at least the 30 largest routers on the network

The top 30 nodes by capacity encompass something like half of network cap - remember, thats not just outbound sats but inbound sats. They need a significant portion of the network committed towards them

2. They then flood the network with htlc's and make them unresolvable, triggering FC's

3. They need to keep the btc mempool congested w/o clearing at over 10s/vb for at least 2 weeks

This is because a default configured watchtower defaults to 10s/vb and default TLV's of 2 weeks on FC's. If they can prevent you and your watch tower from broadcasting the closing state, they can publish it themselves, ascribing themselves the balance of that channel.

4. The threat actor hopes he gains more BTC from vulnerable node ops than he does from triggering justice tx's from good node ops. You could even take into account the value of inbound liquidity and the assumed loss of fee revenue bc they were running a huge router network!

How to mitigate? Increase default config settings, currently this can mean paying more than you need to for closes. LND is putting effort into bettering fee estimator

Hopefully that helps y'all think on if this is an actionable vulnerability or not!

PS for nerds out there: the authors claim that their k lopsided weighted max cut problem hasn't been studied before... I found a stack exchange post giving a 1/2 approximation algorithm within 5 minutes of googling

would take w grain of salt

fun little experiment is querying the graph with your own node -- using BOS on LND you'll probably get a number around ~1200 btc

Plebs should take note that this entity has hundreds of BTC in Lightning - it might help temper routing fee expectations :)

Though, their main revenue stream, selling channels, probably overshadows this by quite a bit

I was running some rudimentary probing thru LNbig a couple weeks back, no hard numbers but inbound shortage is v apparent. You can see this in the difficulty it can take in trying to rebalance lnbig channels

Yes I'd classify LN+ seperately, no actual buying/selling occurs there atm. Swaps are essentially "I'll open a channel to Bob if Alice opens a channel to me" -- it is not a very selective process and the 'quality' of peers highly varies, you basically open a chan to random peer and receive a random chan in return. Some swap peers are great, some are bad. Contrast that to Magma where you may be selective in your peer or to Pool which uses an internal scoring system

Sorry just seeing this lol

Yes, something like a sum of all capacities across these respective router networks would be very cool- potential for seeing overlapping channels, avg fee rates to X peer etc. And plugging those 'tags' into your notifications and what not

I like to see their outbound fee rates to certain destinations and also their inbound fee rates from certain sources before purchasing

cheers

BitcoinVN anycoin.cz Portico exchange is a new one

ZFR is the best inbound to buy as a merchant/service, but ensure fees on other channels are high enough to prevent draining it. I do not recommend purchasing ZFR as a router, tho can make sense in a bootstrapping sense

Purchasing LNBIG inbound is highly unreliable, they have at least a couple hundred BTC inbound shortage

Magma selling faces the largest addressable market, being implementation-agnostic and requiring no client. However they take a decent cut now (1000ppm unless you sub). Magma seems to have facilitated more volume in the last month than Liq Ads or Pool and is much much easier to use and sell with than others

Pool can garner the highest premium in my experience, and interfaces with the largest implementation, tho requires client and some know how. Voltage plugs into this to make it somewhat easier. Additionally, to use Pool well you need to layer a lot of liquidity at different rates / lease lengths

Not much experience with CLN liq ads, though addressable market is currently relatively tiny

I forward on average a little over 1 Btc / day profitably (different node than this SN ID haha) . Mix of manual and automated

I think you're spot on with that liquidity flow you described, and many have posted some great router docs. Ill share a bit of my thoughts

As a pleb, I think many would be better off identifying and focusing on a SPECIFIC flow rather than trying to act as a generalized router. Plebs with 1 BTC are never going to compete against the big 40BTC+ router hubs in terms of real routes - its a liquidity game, and they have more than you

What I mean very specifically by this is, focus on facilitating a specific flow. Breez -> WOS is one example that I know is quite profitable ;) . I think many would do much better for themselves and expend less effort to focus on providing a highly reliable route for such flows, though there can be challenge in identifying such

cheers

very nice :)

Id like to see aggregated data on individual liquidity networks like LNBig, Zap, LQwD Could then also plug those groupings into notifications, peer analysis, etc