Torq (formerly LN Capital)
LN Capital

Liquidity management & analytics software for large Lightning nodes.⚡️

Public Key

npub1kn860wn93ky8vnnzm5x5pdkl8npemzn3lcdagj9zdwf98ytwd89sxgxkhm

NIP-05 Address

Profile Code

nprofile1qqstfna8hfjcmzrkfe3d6r2qkm0nesua3fclux75fz3xhyjnj9hxnjcpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qyw8wumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctvg6q98k

Publishing to

nostr-pub.wellorder.net

nostr.bitcoiner.social

relay.damus.io

Author Public Key

npub1kn860wn93ky8vnnzm5x5pdkl8npemzn3lcdagj9zdwf98ytwd89sxgxkhm

Show more details

Last Notes

2023-10-11 16:56:06 UTC

🚨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
https://image.nostr.build/5d484ee55018d920f00bc9b7474464bf573b27fe00d53bc3668a801531590242.png

2023-10-03 17:01:50 UTC

- reply

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

2023-10-03 17:00:54 UTC

- reply

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

2023-09-29 14:59:49 UTC

Do you run a Lightning node?
Why or why not?

2023-09-29 14:59:15 UTC

- reply

We have a bunch of random ones😂

2023-09-28 16:10:27 UTC

Bitcoin฿
Lightning⚡️
Nostr🟣
This is the tech stack of the future.

2023-09-26 16:07:08 UTC

⚡️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

2023-09-24 17:18:44 UTC

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!

2023-09-22 20:20:15 UTC

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!😎

2023-09-18 14:06:02 UTC

- reply

thanks ser
does amethyst work on desktop?

2023-09-18 13:41:45 UTC

does anyone know a client with good account management?
i.e, switching between nsecs easily and quickly?
thanks😄 #asknostr

2023-09-18 13:36:37 UTC

gm nostr

2023-04-25 20:49:29 UTC

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

2023-04-24 13:57:28 UTC

- reply

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

2023-04-16 14:18:08 UTC

- reply

/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!

2023-04-16 14:16:54 UTC

- reply

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!

2023-04-16 14:15:52 UTC

- reply

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

2023-04-16 14:13:57 UTC

- reply

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

2023-04-16 14:13:45 UTC

- reply

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.

2023-04-16 14:13:25 UTC

- reply

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

2023-04-16 14:13:12 UTC

- reply

With Schnorr Signature key aggregation, multi-sig outputs look exactly the same as single sig outputs on-chain.
This makes it impossible for chain analysis firms to distinguish between multi-sig and single-sig spends.

2023-04-16 14:12:59 UTC

- reply

Essentially, key aggregation is a way for multiple parties to combine their public keys/signatures into a single public key/signature.
The privacy implications here are mind-blowing.

2023-04-16 14:12:47 UTC

- reply

3/
Key aggregation is like making that big magic key.
People have special codes (keys) that they use to show they agree on something, like moving bitcoins.
Key aggregation lets them mix their codes together and make one big code that works the same way.

2023-04-16 14:12:34 UTC

- reply

2/
Now, imagine there's a new way to open the toy box.
Instead of carrying all the magic keys separately, you can mix them together to make one big magic key.
This big key can open the toy box just like all the little keys could, but now it's easier to carry and use.

2023-04-16 14:12:22 UTC

- reply

Here’s a quick explanation of key aggregation:
1/
Imagine you have a special toy box that can only be opened with a magic key.
You and your friends each have your own magic key, and when you want to open the toy box together, you need to use everyone's magic keys.

2023-04-16 14:12:12 UTC

- reply

Schnorr signatures offer many advantages over ECDSA, including space and fee savings.
But the most significant advantage offered by Schnorr signatures is key aggregation.

2023-04-16 14:11:58 UTC

- reply

Until November 12th, 2021 (block 709,632), ECDSA was the only signing algorithm that Bitcoin used.
However, on that day, Taproot was activated, which allowed for the use of Schnorr signatures.

2023-04-16 14:11:43 UTC

- reply

In this thread, we’ll just focus on Schnorr Signatures (BIP 340), as they are the main contributor to the privacy benefits.

2023-04-16 14:11:24 UTC

- reply

So how does Taproot solve part of this problem?
Taproot introduced three individual BIPs:
-Schnorr Signatures (BIP 340)
-Taproot (BIP 341)
-Tapscript (BIP 342)

2023-04-16 14:10:47 UTC

- reply

It’s well known that Bitcoin has a privacy problem.
Tracking UTXOs from KYC exchanges is trivial, and specialized firms like Chainalysis have cropped up for this very purpose.
As Bitcoiners, we should care A LOT about privacy.
It’s a fundamental human right, after all.

2023-04-16 14:10:23 UTC

Taproot unlocked the future of Bitcoin Privacy
But most Bitcoiners have no idea why it’s so important.
A KEY AGGREGATION THREAD:
https://media.nostrgram.co/i/5a/media_5ad699c10c346.jpg

2023-03-05 16:14:04 UTC

#Bitcoin's scripting language was a genius foresight.
Satoshi was thinking light-years ahead when he added this programmability.
Bitcoin Script: A Beginner’s Guide:
https://void.cat/d/BW5AgaGB1fH8udfqq1iTzc.webp
1/
What is script?
Script is a simple programming language that is not Turing complete.
It lacks certain logical functionality, including loops, to prevent people from spamming the network and harming nodes.
Script logic is used to check the validity of signatures in bitcoin transactions.
If a script is valid- nodes will relay the tx to other nodes.
Script executes in a stack data structure, similar to an array.
The most common script type is Pay to Public Key Hash (P2PKH), a simple script that pays to the hash of a public key, otherwise known as an address.
https://void.cat/d/WwDipeyq5p49bja8TiQV6j.webp
However, since the advent of SegWit, we’ve seen a marked increase in the amount of Pay to Witness Script Hash (P2WSH) outputs.
https://void.cat/d/137dnNCo9cF1VBdRHshAJx.webp
There are many different types of Script, including:
Pay to Pubkey (P2PK)
Pay to Pubkey Hash (P2PKH)
Pay to Script Hash (P2SH)
Pay to Witness Pubkey Hash (P2WPKH)
Pay to Witness Script Hash (P2WSH)
Pay to Multisig (P2MS)
Pay to Taproot (P2TR)
NULLdata (OP_RETURN)
The simplest script is Pay to Pubkey.
It has one operator, “Checksig”.
All it does is compare the signature of the tx to the public key, to verify that the signature could only have been produced by the person with the private key that was used to derive the public key.
https://void.cat/d/JGZN56MyAHfj1L11ZmoMYs.webp
In fact, the first-ever coinbase transaction from the genesis block in 2009 was a Pay to Pubkey output.
https://void.cat/d/SfWbL8CqBKdirtEF8sSSch.webp
There are tons of different functions that script can execute.
They are defined by the Opcodes used to construct the script.
Here are some of the most common Opcodes:
https://void.cat/d/DyEwVUJhtf8cXu2Mdxn1BR.webp
The SHA256 and RIPEMD160 functions are pretty straightforward.
They just compute the hash of a given input.
CHECKSIG consumes a public key and checks the validity of a signature, like in the Pay to Pubkey example.
CHECKMULTISIG consumes multiple public keys and multiple signatures, and checks to make sure that there are enough valid signatures to unlock the BTC.
You can also execute addition, subtraction, duplication, and a myriad of other functions.
TLDR;
Bitcoin Script is a simple programming language that isn't Turing complete.
It’s used to lock and unlock bitcoin, not to build applications.
Nodes run script when they receive a tx to verify its validity.
Opcodes execute different functions within a script.
We hope you learned something new from this thread!
Special thanks to Greg Walker for his amazing tutorials and graphics.
Follow us for more Bitcoin and Lightning content.

2023-02-26 17:10:05 UTC

#Bitcoin is built on digital signatures.
But what does it actually mean to sign a transaction?
You should know this.
Nostr Thread:
https://void.cat/d/QV7YekJ7QxGUDMAouW3uAN.webp
Everyone knows that we use our private keys to send bitcoin.
But how do we send bitcoin *without* revealing our private key to the whole network?
This is where digital signatures come in.
We start with a basic private key.
Your private key is an incredibly large, random number that you (or your wallet software) can generate with random entropy (dice rolls, mouse scrolling…etc).
Your private key (the really large, random number), gets multiplied by a generator point G (a point on the secp256k1 curve) to generate a public key.
https://jun-wang-2018.github.io/MyBlog/en/ECDSA-and-Bitcoin-I/multi.png
This is what a raw pubkey looks like:
https://void.cat/d/JU5uz8iNZrs8ZNjnak5YHL.webp
The raw public key then gets hashed into what we call an “address”.
This address is secure enough to send to the bitcoin network.
https://void.cat/d/44AaPzz7cvbzvLwMYjYd9j.webp
After you’ve created an address, you can give it to someone who wishes to send you BTC.
To send you BTC, they lock the transaction to *your* public key.
Since you own the private key that was used to derive your public key, you now have the ability to spend (unlock) the BTC.
This is where it gets interesting.
To send the bitcoin on, you need to prove that you created the public key that the tx is locked to.
To do this, you use your private key to generate a signature using the elliptic curve.
This signature allows you to send the bitcoin, without directly revealing your private key.
To sign a transaction, we use a combination of three components:
1. A random number
2. The hash of the transaction (often called the message)
3. Our private key
We take our random number and multiply it by the generator point on the elliptic curve.
This gives us a random POINT on the curve.
We then multiply this random point by our private key.
We add the hash of the transaction to that result.
What we end up with, is a value that represents a pathway between our private key, and the random point on the curve.
We broadcast the signature and transaction data to the network, and each node will verify if the pathway we have constructed is valid.
Or in other words, the nodes check to see if we indeed have the private key which corresponds to the public key that the tx is locked to.
If the signature is valid, the bitcoin is unlocked.
The transaction gets mined into the blockchain, and locked to the public key of the recipient.
To get into the details of this verification process, we might need another thread 😂
Let us know if you’d be interested in that!
Thanks for reading, we hope you learned something from this one.
If you want to learn more, we highly suggest Greg Walker's tutorials here: learnmeabitcoin.com
Follow us for more bitcoin & lightning threads!
Oh, and if you run a Lightning node, definitely check out Torq, the tool we’re building for node management:
https://github.com/lncapital/torq

2023-02-19 18:09:25 UTC

- reply

thanks!

2023-02-19 16:20:41 UTC

- reply

yup😎

2023-02-19 16:03:29 UTC

Lightning took Nostr to the next level.
But BOLT 12 will take it even further.
BOLT 12 + NOSTR = THE EVERYTHING APP
Nostr Thread:
https://void.cat/d/Trsk2DRaQxSzao5H2m5ViT.webp
If you didn’t already know, BOLT stands for Basis of Lightning Technology.
BOLTs are like BIPs for the Lightning Network.
BOLT 12 is already supported experimentally on Blockstream’s Core Lightning and is also being actively implemented by the teams at Acinq, LDK, & Lightning Labs.
BOLT 12 is distinct from BOLT 11 (the current invoicing spec on LN) in a bunch of different ways.
The main component of BOLT 12 is a new type of invoice called an “offer”.
An offer can be thought of as a ‘meta’ invoice- an invoice on top of an invoice.
Offers are useful because they are persistent and static.
This means that you can use them for donation pages, billboards, and zapping fellow plebs on Nostr!
BOLT 11 invoices, on the other hand, can only be used once, and must be generated in real-time.
BOLT 12 offers also allow you to create recurring subscriptions denominated in sats OR dollars.
This could be used to fund paid relays or creators (Patreon style), and for other subscription services.
BOLT 12 is Lightning native, which means that it’s different from LNURL/Static LN addresses because you aren’t required to run a web server to generate invoices.
Your Lightning node handles all the work.
This allows for fully self-custodial zapping⚡️
TLDR;
BOLT 12 would be a dramatic improvement for Lightning and Nostr.
BOLT 12 allows for:
-Subscriptions denominated in USD (but settled in sats)
-Static Zapping
-Self-Custodial Zapping
Thanks for reading.
We’re going to start posting all our threads on here.
Follow for more!
Also, if you run a large Lightning node and you haven’t tried Torq yet, you’re seriously missing out!
Check it out on Umbrel & Btcpayserver or download it straight from GitHub:
https://github.com/lncapital/torq

2022-12-22 15:46:35 UTC

- reply

😆

2022-12-22 15:42:35 UTC

This place seems cool👀