🚨Excited to announce Torq v1.2.0! 🚨

This release includes:

-A refined dashboard🔥

-Advanced workflow channel filters✅

-CLN pagination support, and much more⚡️

Check out all the new features and improvements on GitHub: https://github.com/lncapital/torq/releases/tag/v1.2.0

nice, yeah all of those solutions are awesome. especially phoenix with splicing🔥🔥🔥

hmmm ok good to know. it's certainly a daunting task at first

Do you run a Lightning node?

Why or why not?

We have a bunch of random ones😂

Bitcoin฿

Lightning⚡️

Nostr🟣

This is the tech stack of the future.

⚡️TORQ DEMO⚡️

Ever wondered what Torq's Lightning node automation & logging system looks like?

In this video, our CEO Henrik Skogstrøm walks you through a quick demo.

Check it out!

https://youtu.be/SgA2eknhSvY

One of the biggest problems in Lightning finally has a solution.

CHANNEL JAMMING–

A Hybrid Approach:

Firstly, what is channel jamming?

Jamming is a type of denial of service (DDoS) attack on Lightning channels.

The goal of the attack is to make a Lightning channel unusable.

To execute this attack, a malicious actor sets up two nodes and sends payments between them.

However, they don’t release the preimage (the secret number that unlocks funds across the route) for each payment promptly, leaving the payment stuck “in flight”.

By sending a payment to themselves, and never releasing the secret, the attacker can let payments “hang” in flight, until the timelock on the HTLC (hashed timelock contract) expires.

This is a problem because each channel can only have a fixed number of in-flight payments: 483.

Side quest:

Why only 483 max “in flight” HTLCs?

Well, it has to do with the maximum size of an on-chain BTC transaction.

If you had more than 483 HTLCs and needed to close the Lightning channel, the transaction would be too large to enforce on-chain.

So, to summarize:

Jamming is a DDoS attack that makes Lightning channels unusable.

Victims of channel jamming cannot send and receive payments or earn routing revenue.

But how big is this problem?

To put it in perspective, an attacker could potentially jam the entire LN for only 500,000 to 3M sats per month (according to Antoine Riard and Gleb Naumenko)

By jamming only 20% of the channels (14,000 channels), the attacker could make the entire network unusable(1).

As you can see now, this is a pretty serious issue.

So what’s the solution?

We are not cavemen, after all!

Channel jamming has been a known problem in LN since 2015.

As you can imagine, there are many ideas about how to properly solve it.

But for this thread, we’re going to focus solely on Carla Kirk-Cohen, Clara Shik, and Sergei Tikhomirov’s “hybrid” approach.

Their approach is a combination of two main ideas:

1. Unconditional fees2. Reputation scheme

Each idea solves a different type of jamming:

Unconditional fees for “fast” jamming.

Reputation scheme for “slow” jamming.

Just to clarify real quick,

Fast jamming is a constant stream of HTLCs that fail instantly (think of a machine gun).

While slow jams remain “in flight” for hours or even days (more like a hostage situation).

1/ Unconditional fees

A fee should be paid unconditionally, regardless of whether the payment fails or succeeds.

Ideally, this would make fast-jamming attacks prohibitively expensive.

However, that may impose too much of a burden on honest users.

A more realistic goal is to compensate the routing node under attack for the lost revenue.

According to a simulation Clara & Sergei built, if we increase the fees paid by just 2%, routing nodes would be fully compensated for any jamming attacks.

So for example, if a normal payment fee was 100 sats, an additional 2 sats upfront on all payments would be sufficient.

2/ Reputation scheme

While fees are great for addressing fast-jamming attacks, they are ineffective against slow-jamming attacks.

For this reason, the hybrid approach incorporates a reputation scheme.

The reputation scheme is local.

Nodes only assign reputation to their peers.

This reduces a ton of complexity, as local reputation requires no coordination across the network.

So how does the reputation scheme work?

Nodes keep track of their peers’ past history.

If a peer forwards honest payments that bring in sufficient fee revenue, the node considers that peer “high-reputation”.

If a peer constantly forwards jams, the node considers it “low reputation”.

Nodes also have the option to “endorse” payments that they forward.

So for example, a payment endorsed by a high-reputation peer is considered *low-risk*.

While an un-endorsed payment from a low-reputation peer may be considered *HIGH* risk.

By using slot bucketing in combination with this reputation scheme, we can limit the number of “in-flight” high risk payments at any given time.

This prevents a malicious actor from fully jamming a channel.

So let’s say the 4 general slots are all jammed.

If an HTLC isn’t endorsed, we fail it.

We don’t allow the un-endorsed HTLC to use up more of our liquidity.

However, if a payment is endorsed from a high-reputation peer, we will forward it along.

Each node can create their own custom parameters for these slots & reputation based on their risk tolerance.

High risk tolerance? Maybe you allocate more slots toward un-endorsed HTLCs.

Low tolerance? Maybe you only forward endorsed HTLCs.

It’s up to the individual to decide.

TLDR;

The hybrid approach combines unconditional fees (for fast-jamming), and a reputation scheme (for slow-jamming).

An upfront fee increase of 2% can effectively repay routing nodes for fast-jamming attacks, and the local reputation scheme takes advantage of HTLC endorsement and slot bucketing to ensure that a given channel can never be fully jammed.

Resources/Further information:

If you’re running a Lightning node, you can help this research effort!

Fill out their survey here:https://docs.google.com/forms/d/e/1FAIpQLScm2xs4hNsrkI8UCBS4aTdO03YrmWT2X0-j6zXWpkZ7keKiUw/viewform?usp=send_form

Check out the BOLT PR here:https://github.com/lightning/bolts/pull/1071

And here’s a summary of the full research paper:https://research.chaincode.com/2022/11/15/unjamming-lightning/

Sources:(1): https://jamming-dev.github.io/book/2-costs.html

That’s it!

We hope you learned something new.

Special thanks to Carla, Clara, Sergei, and Chaincode Labs for their awesome work on this🙏🏻

Follow us for more!

We just wrote a fascinating thread on LN channel jamming.

If this note gets 10 likes we'll drop it a day early on nostr!😎

thanks ser

does amethyst work on desktop?

does anyone know a client with good account management?

i.e, switching between nsecs easily and quickly?

thanks😄 #asknostr

gm nostr

https://void.cat/d/512as1REQh1Pm7kEP4JRRh.webp

ahh, ok. next time we'll just a make a long note. the problem is using the images and links. sometimes the client won't relay it

/end

We hope you learned something today.

Follow us @LN_Capital for more threads like these.

Also, if you run a Lightning node, be sure to check out Torq, link is in our bio!

The BIP still needs to be tested, but once approved by consensus, the community can begin to activate it.

The activation will ultimately be decided by the nodes on the network.

We hope to see key aggregation in the wild soon!

So can we use key aggregation today?

A draft BIP was just submitted to the Bitcoin Core repository.

https://twitter.com/real_or_random/status/1640337134199640065

And since LN channels inherit the privacy of the UTXOs used to fund them, this will be a huge improvement.

Schnorr sig aggregation is also a huge improvement to the Lightning Network.

The LN relies on 2-of-2 multisig transactions for channel opening.

With Schnorr aggregation, LN channel opens will look exactly the same as any other single-sig output on-chain.

*evil laugh*, cypherpunks win again, Monero shills in disbelief, etc..etc..