Posted 25 days ago by mccormackpartners
Here's a quick overview on what we have covered (so far) with All Things Bitcoin.
Posted 27 days ago by InternationalRoutingService
The latest version of C-Lightning version 0.10.1 it has a new functionality of dual funded channels and liquidity advertisements.
This requires at c-lightning verison 0.10.1 and the experimental dual fund option switched on. This can be enabled by setting the option experimental-dual-fund within your configuration file. Or you can pass the flag --experimental-dual-fund when starting clightning.
Dual funded channels
With dual funded channels, a single channel can be opened up between two nodes with funds contributed by both nodes enabling liquidity on both sides of the channel. This creates both inbound and outbound liquidity between two nodes on a single channel creation.
Liquidity market built into the lightning network
And now c-lightning nodes can also advertise liquidity offers directly within the lightning network. Any c-lightning node can offer liquidity and find other c-lightning nodes advertising liquidity. By default liquidity leases last for 4032 blocks, approximately 1 month.
When requesting inbound liquidity from a c-lightning node you can optionally dual fund it on your side also for a partially or fully balanced channel to compliment your inbound liquidity. Or else you can just request inbound capacity as long as you have enough funds in your wallet to pay for the lease.
At the time of this writing there are 9 nodes advertising liquidity on the lightning network using this feature. You can search for nodes offering liquidity and their rates with the command
lightning-cli listnodes | grep -B20 -A7 option_will_fund
You can view the information for a specific node using the listnodes command which also contains information on liquidity offers. For example, to get information on my node you would type the command
lightning-cli listnodes 03a7c61c056023c804c6d63693345e00ed8e2b28c8d2e0c455964bfff31128df40
I am charging 0 fees on channels in opened through this offer. And charging 60 basis points 0.6% on inbound liquidity. For example if a node is requesting 5,000,000 sats of inbound liquidity my node would charge 30,000 sats when the channel is opened. Right now my node is earning sats on leasing liquidity instead of transaction fees. At the moment most or all of my channels have zero fees.
My node is a tor only node. At some point I plan to get a clearnet proxy for it. If your node has tor installed you can connect to nodes both on the clearnet or tor. If you do not have tor, a tor node has to first connect to you.
To connect to my node and request inbound liquidity you can use the following two commands. You will want to adjust the variables amount= and request_amt= in the second command. amount= is how much you are funding on your side of the channel. request_amt= is how much inbound capacity you are requesting to be leased. The "compact_lease" in this example is accurate at the time of this writing. If this command does not work you will want to check for the latest compact_lease ID. You can find the current compact_lease ID with the listnodes command mentioned earlier.
lightning-cli connect firstname.lastname@example.org:9735
lightning-cli fundchannel -k id=03a7c61c056023c804c6d63693345e00ed8e2b28c8d2e0c455964bfff31128df40 amount=0sat request_amt=50000000sat compact_lease=029a003c000000000001
Posted about 1 month ago by LND ⚡ Routing
Benefits of using our service:
- Actively managed liquidity, virtually guaranteeing successful payments up to your channel size.
- Large channels to popular destinations and major routing nodes.
- Open channels to any node, for a friend, or to your favorite service provider.
- Private LN-only interface via Tor, minimizing our attack surface and maintaining uptime.
- Fast clustered servers for reliability.
- Up to 1.5BTC channels, minimum 100k sats. Larger available on request with proven routing history.
- Competitive pricing and fees.
See https://github.com/lnd-routing/lnd-routing/ for channel opening instructions.
Open an outbound channel to us any time for routing and making payments.
Posted about 1 month ago by BTC Sessions
Posted about 1 month ago by Tony Stark
I'm a small time miner and instead of trading or hodling that Bitcoin, my plan is now to start adding a channels, capable of 2M sats per fortnight. I WILL ROUTE TRAFFIC your way, maybe slow to begin with, but we all need to start somewhere.
I really want to see this flourish, so what better than to improve the network with liquidity, and grow the network for all those that come after me.
If this resonates with you, join a channel with me!
Viva La Revolution
Short the banks
Down with the FED
Posted about 1 month ago by Reckless_Satoshi
In the cover image Reckless_Satoshi is wearing a hoodie, which indicates he is up to something.
Whom did I attack? Well, here the complete list of offended services Bitfinex, OKex, Muun, WalletOfSatoshi, LNMarkets and Southxchange. If you are reading this to make a 'quick sat' I am sorry to disappoint you, I am publishing these findings only after the susceptible services have been contacted and flaws fixed :)
Cheap, but not free. A simple attack.
Simple, deposit funds into a custodial service then withdraw the funds, done. Congrats for your profit! I am sure you are thinking -"Those sats were mine anyway, right? How does this qualify as an attack?" Well, I forget to mention we also need to place a node that will be routing the payments between the custodial service and the receiving node. The routing node will collect a fee, hopefully the fee will be big enough so there is a net profit (i.e., withdrawal_fee + deposit_fee < routing_fee_collected). If a positive net return is possible, then it is just a matter of optimizing the size of the fee collected and the transaction speed rate to see how big the damage could be. It is easy to see how this attack must be feasible on any service with free withdrawal fee.
How do you place a node in the middle? Well, the sending node is in charge of selecting the route. A priori, it seems unlikely that the sender will select a very expensive route. However, there is a case when the sender will certainly have to send the payment trough our routing node. We will connect our receiving node to the Lightning Network only with a single channel to our routing node. Therefore payments, if they arrive at all, must always be relayed by ourselves.
Our receiving node is only connected to the Lightning Network through our routing node. Green arrows represent revenue, red arrows are costs.
In the case depicted in the figure, our routing node is directly connected to the custodial service. This is ideal to optimize the attack: the deposits have no cost, HTLCs will settle quickly, and we avoid the limitations set by other routing nodes using CircuitBreaker (payments fail when a few HTLCs are pending). If the attack is successful, having a lot of inbound liquidity from other nodes is key. The channel to the custodial service will quickly become unusable as we have stolen the liquidity to our side. Therefore, you want to desaturate it by circular rebalancing. Once we free up inbound liquidity from the custodial service, the channels to our liquidity providers will be saturated, we can chose to close those and move the profits on-chain or we could loop out (not sure which process is less costly: we are making free BTC, does it even matter?)
This is one of the simplest attacks. In fact, the only LN attack I can think of, but also I am just a newbie in the process of learning. I assume there is people out there much more capable of conducting this research. Who knows, maybe there has been sizeable loses in the past that remains undisclosed.
Bitfinex has a fixed 100 sat withdrawal fee. However, it is obvious that some withdrawals requests might cost to route more than that. I was curious to see if withdrawals that are more expensive would be processed at all: and yes, they are processed. It is my believe, after a bit of tinkering, that Bitfinex would execute any withdrawal where payment routing fee is below 10 000 ppm (1%). I gave a try to withdraw 100K sats and collected 1000 sats in fees on the middleman node.
Making a net profit from Bitfinex is possible (at least net positive 900 sats per deposit/withdrawal cycle), however withdrawals might quickly get halted as there is a "processing" step on their end probably rate limiting transactions. Bitfinex's API does not seem to support yet withdrawals for the symbol 'LNX' (these require an invoice instead of an address). So while it is possible to profit from Bitfinex, I didn't go the next step to script and optimize the attack. In any case, I filled out a report with their security team before making this public. Their site explicitly indicates that they might no reply to a report if they were already aware. As I received no reply I assume it's safe for this insight to go public.
The fee charged by OKex seemed to be strictly equal or higher than the cost to route the payment. There is no way one could make a net profit from OKex using this attack.
3. Muun wallet
LNmarkets is possibly one of the coolest LN services out there. The use of LNURL qrcodes to login, deposit and withdraw makes it the most LNish experience out there. It truly displays what the LN is capable of, in addition, their API documentation is simply superb. Unfortunately, their effort also made it very easy for me to script and optimize the attack. Since the service had a free withdrawal fee, it was indeed profitable.
According to some quick testing, LNMarkets is willing to route to you any payment as long as the fee does not exceed 10 000 ppm (1%). The maximum deposit/withdrawal amount is 1m sats. As you can see, theoretically one could expect to make a net profit of ~10K for every deposit/withdrawal cycle. Each cycle takes around 20 second (this will greatly depend on whether the nodes are behind TOR or Clearnet). Using two threads, that makes for a profit of about ~4 million sats/hour .
At 4 m sats/hour the full outbound liquidity of LNmarkets would have been stolen in 80 hours (totaling 3.3 BTC, LNMarkets is open about their outbound liquidity on their own site). The script ran for 6 minutes, collecting about 450K sats in fees before some failsafe halted platform withdrawals for all users. About ~2 million sats were locked into the platform, for a net loss of ~1.5m sats. However, LNMarkets guys have been exceptionally cool about this and returned the sats to me. They certainly did not have to, but I appreciate it and shows they strive to build a healthy community.
LNMarkets is now charging the routing fee to the user. It is a fair and sustainable solution, although it muddies the user experience. The beautiful thing about lightning is that if the users wants often and free withdrawals, they can just open a channel to LNMarkets for the price of a single on-chain fee.
Southxchange LN withdrawal fee is free. I tinkered a bit to find the maximum their node would be willing to pay for a successful routing. I think it was about 50 sats flat as maximum, but maybe it was higher. Even when I was withdrawing 1 sat, their payment was sent with 50 extra sats for routing. That's an effective 50 000 000 ppm (5000%) fee being collected!
It was possible to deposit 100K sats and then withdraw 1 sat a time. Of course, 50 sats is a negligible amount. However, their API works flawlessly and I noticed there was no request rate limit. I wrote a simple python script able to generate local LN invoices and submit them to the exchange to process the withdrawals. It reached top speeds of up to ~300 withdrawals per minute (200 ms per withdrawal), simply wow! That makes for ~15K sats per minute. I did not optimize further the script, as the channel was already near being maxed out (current maximum pending HTLCs for a channel is 483 and they were taking long to settle). In addition, my RaspberryPi was getting CPU limited, I believe due to encrypting/decrypting the onion packages. It would have been possible to improve the attack speed by a lot with better connection and some parallelization (more accounts / more machines / more routing nodes).
Without any further optimization, at a rate of 900K sats / hour the full outbound liquidity of Southxchange would have been depleted in ~50 days (assuming there being 10 BTC or ~1/6 of the node capacity). I stopped the script after one hour as there seemed to be no limits or failsafe whatsoever. A malicious attacker could have definitely withdrawn most liquidity in hours.
After the attack, Southxchange has opted for rate limiting withdrawals for the user (1 every 10 minutes), but they are still free. In my opinion, this is not the optimal solution. It affects the experience of legit users that need frequent withdrawals: in-and-out quickly, minimizing exposure to custionals, this is what lightning is about. Yet, this solution also fails to prevent future attacks, as you can still get around this limit with many accounts. Instead, I would suggest charging the withdrawal fee to the user: you gotta pay what things cost. If the user wants free withdrawals, they can 'go premium' by opening a channel to the exchange's node.
If a service has free withdrawal, users are more compelled to take their BTC into self-custody between operations (it is free, why wouldn't you?). So, I am not totally sure of what I am about to say, but I have the feeling that custodial services with free transaction fees might be artificially increasing the number of transactions, therefore subsidizing nearby routing nodes. This might induce weird incentives for the creation of channels and the deployment of liquidity; hence, affecting how the lightning network grows. Yeah, sounds far-fetched, but even if tiny, there must be an impact (no idea if positive or negative impact).
- This is one of the simplest attacks anyone can think of using LN, yet surprisingly, many services are susceptible. I believe that if an actual smart and malicious actor had performed it, he could have withdrawn a big chunk of the outbound liquidity of some of these nodes.
- By attacking ourselves the LN and publicizing the findings, we make stronger the Lightning Network and its services. Maybe soon we will be reading sensationalist headlines such as "The Lightning Network has been hacked" every time a custodial service using LN is exploited. It is in our hands to prevent FUD to spread also over the amazing lightning features.
Finally yet importantly, I would like to apologize for the disruption caused to the service maintainers and thank them for their excellent sportsmanship. It has been a great deal of fun to learn how these futuristic services work.
I'm sharing code to replicate my findings on GitHub fee-siphoning. So far, only LNMarkets, I will not share yet Bitfinex and Southxchange as I am not 100% confident that they are exploit proof after their fix.
Let me know in the comments if there is any LN enabled service that I should test. I went for all of the big ones already but I might make a second round :)
# - Reckless_Satoshi
If you enjoyed my little research project, you can say hi by opening a channel to me or via keysend (02ce13573f6ab577088cead4379dc64f300ffbeca2ae040beee9f3541ccc4427c7) or LNURL (LNURL1DP68GURN8GHJ7MRWVF5HGUEWVDHK6TMVDE6HYMRS9ASHQ6F0WCCJ7MRWW4EXCTECXQUSW77KS4).
Posted about 1 month ago by LN+
The idea behind private swaps is to enable groups of friends to organize swaps among themselves. The creator of the swap should send the URL of the swap and the pin code provided by the LN+ interface to join the private swap to their friends over private communication channels.
Please be aware that the swap page itself is publicly visible on the web, and the opened public channels will naturally also be public on the LN gossip network. If you want the channels to be fully private and inaccessible to the public Lightning Network, you will need to open private channels and organize the swap outside of LN+. If there is a need I can implement support for fully private channel openings, but my goal is to keep LN as open as possible, while serving the needs of LN node operators.
If you spot any bugs, or have any comments, please reply here or send me an email.
Posted about 1 month ago by MicelioMadrid
Posted about 1 month ago by Umberta
Posted about 1 month ago by sackof.w4ge.com
I've customised the config file to set 0 base fees across all channels unless there are low sats left on my side (in which case use 9999 base fees to effectively disable routing from my side).
All channels get a proportional fee per ppm. So if there is a high balance on my side the fees will be low and as my balance decreases the fees increase.
No more manual channel config changes :)