LQWD Technologies Corp., an infrastructure and liquidity provider for the Bitcoin Lightning Network, has announced a new partnership with Amboss Technologies Inc. to become their premiere Lightning Network Liquidity Service Provider (LSP), according to a press release sent to Bitcoin Magazine. As part of the partnership, LQWD will contribute an initial 10 Bitcoin in liquidity to Amboss, with plans to deploy more Bitcoin throughout the collaboration.

“Partnering with LQWD ensures that Amboss’s global customers have direct access to institutional-grade liquidity for Bitcoin payments, allowing LQWD to generate additional yield through their nodes on the Lightning Network,” said Amboss Co-Founder and CEO Jesse Shrader. “Additionally, this partnership increases the supply side of Amboss’s liquidity marketplace, enabling LQWD to fulfill the market demand for Lightning Network liquidity.”

Amboss Technologies specializes in data analytics solutions tailored for the Bitcoin Lightning Network and provides products like Magma and Hydro for market organization and liquidity automation. Magma serves as a liquidity marketplace, while Hydro enables advanced liquidity automation for seamless Lightning Network payments.

“This partnership enables LQWD to deploy more of our company-owned Bitcoin while potentially capturing significant transaction volume and generating yield on our Bitcoin holdings,” stated Shone Anstey, Chief Executive Officer of LQWD. “Importantly, we maintain full sovereignty and custody throughout the process. This strategic alliance signifies a significant step forward for both LQWD and Amboss, as we work together to enhance liquidity and efficiency within the Bitcoin Lightning Network ecosystem.”

The Lightning Network (LN) has witnessed significant growth, with LN activity increasing by 1,200% over the past two years, according to the release. This surge in adoption, coupled with the integration of stable coin transaction capability, opens up LN to a wider user base and attracts forward-thinking businesses and Bitcoin exchanges looking for faster and cheaper payment solutions compared to traditional rails like Visa and Mastercard.

Source link

Commerceblock has released a new atomic swap protocol for use with statechains on their Mercury Layer protocol. The HSM server has introduced functionality to support atomically swapping two statechains, as well as enforcing an atomic exchange of a statechain for a Lightning payment. This is the first example of concretely defined and built interactions between statechains and the Lightning Network. Synergy between both protocols has been postulated since the concept of a statechain was originally proposed by Ruben Somsen, specifically as a way to solve the limitation of having to transfer a whole statechain UTXO at once.

Basic Statechain Swaps

In order to support the new swap protocols, the HSM server needs to add some new fields to its database entries tracking each statechain it is facilitating. To facilitate the statechain to statechain swap, the server needs to track:

• Batch_id: a value to associate statechains being swapped in a group.
• Batch-time: a time that starts a counter after which the statechains can be “reclaimed” if the swap fails.
• Locked: a value indicating whether or not the statechain is locked and restricted from regular transfers.

This allows the HSM server to track and enforce all the variables necessary to ensure a safe atomic swap. When initiating a swap, users have to communicate with each other directly in order to establish a shared batch_id between them. From this point they trade all the necessary information required to facilitate a normal statechain transfer, and send that information plus the batch_id and batch-time to the server. They essentially start the regular transfer process, but also attach the variables to connect the individual statechains as participating in a swap together and how long the timeout period is for that.

The server at this point will apply a lock to every statechain using the same batch_id in the transfer process. Until the timeout expires, or all of the statechains in its database using the same batch_id have been unlocked by the current owners, the server will not approve any transfers. A neat thing about the way the HSM enforces the swap logic is that it doesn’t matter who contacts the server first. When the server gets a message using a batch_id, it checks every statechain in its database and if there is a pre-existing batch-time for that batch_id it sets it as the same. This ensures that no matter who registers the swap first they all use the same time value for the timeout function.

Each client involved in the swap at this point checks for and downloads the messages that initiated the transfer protocol, and upon verifying they’re correct sends a message to the server to unlock their statechain, removing the transfer restrictions. Whenever anyone attempts to finalize a transfer on the receiver side of any of the statechains involved in the swap, the server checks to make sure all of the statechains with the same batch_id are unlocked. If even a single one with the related batch_id is still locked the server will finalize a transfer for none of them. If a swap doesn’t succeed before the timeout, the server will continue restricting the finalization of the swap transfer, but will let the current owners initialize a new transfer to themselves to effectively cancel the swap.

Lightning Latch

The Lightning Latch functionality, swapping a statechain for a Lightning payment, works very similarly to the statechain to statechain swap. Here are the new fields the server must track for the Lightning swap:

• Batch_id: a value to associate statechains being swapped in a group.
• Batch-time: a time that starts a counter after which the statechains can be “reclaimed” if the swap fails.
• Pre-image: the preimage of the Lightning payment, which is generated by the HSM server.
• Locked_1 and locked_2: there are two lock fields for the Lightning swap, one authorized by each user involved.

Just like with the statechain to statechain swap, the users establish and share a random batch_id. The current statechain owner then messages the server with the batch_id and statechain involved and requests it generates a hashlock preimage for a Lightning payment. This user then generates a Lightning invoice using this preimage, and the second user contacts the server to confirm it generated the preimage. The current statechain owner then begins the statechain transfer process and uploads the transfer message to the server.

After confirmation of that, the second user trying to swap for the statechain initiates the Lightning payment. At this time the server is the only one with the preimage, so the statechain owner cannot finalize the payment yet. The current owner after verifying the pending Lighting payment sends the server an unlock message to remove the first lock on the statechain. The receiver finally verifies the transfer message, and if valid messages the server to remove their lock as well.

Now with both locks removed, the HSM server will release the preimage to the current statechain owner to finalize the Lightning payment, and will finalize the statechain transfer to the receiver.

This scheme does require trusting the statechain operator to function honestly, but that is fundamentally not a change to the pre-existing trust model of using a statechain in general. At no time does the operator have control over users’ funds, nor do they learn anything about the Lightning payment details.

What Is This Good For?

This scheme is a far cry from the originally posited interaction between statechains and Lightning channels, stacking one on top of the other, but even as a simple starting point this presents functional utility for existing Lightning users. Rebalancing channels is a necessary thing for many nodes, if the capacity is entirely pushed to one side or the other the utility of that channel is limited for routing payments. Many businesses and users have started experimenting with using Liquid as a mechanism for this due to on-chain fees rising and making swaps into and out of the Lightning Network more expensive.

Statechains offer an alternative mechanism to a federated sidechain to alleviate some of the fee expenses associated with channel balance management. Instead of having to swap out to the mainchain directly, or use a sidechain, funds can be swapped to a statechain and held there until they are needed for swapping funds back into a channel. Similar savings in fees can be had while still maintaining the ability to unilaterally claim your funds on the mainchain.

Another potential use case (TRIGGER WARNING) would be the possibility of more efficient marketplaces for trading ordinals. Since ordinals are simply an index scheme tracking paths backwards in the transaction history to specific satoshis, they can easily be lifted off-chain onto a statechain. That dynamic in combination with Lightning Latch could allow cheaper and faster off-chain purchases of ordinals. Someone could build a marketplace where they can be sold instantly off-chain over the Lightning Network.

It’s even possible one day if Lightning clients could become aware somehow of which statechain operators specific Lightning nodes trust that Latch could be used to help route payments by passing statechains around between different nodes instead of using conventional Lightning channels.

On the front of pure statechain to statechain transfers, this offers the potential for a message passing layer to recreate coinjoin like system mixing coins off-chain, similar to the original mixing functionality in Commerceblock’s first statechain implementation.

While it is a very simple starting point, Lightning Latch and the statechain swap functionality crack open the first door of statechains integrating into the existing Lightning Network – and other similar layers to come in the future – in a way that lets them all integrate seamlessly and function as a singular network in terms of payment routing and liquidity management. Even while we debate the need for and usefulness of covenants, there is still quite a lot of room to continue building with what we already have. 

You can listen to the Commerceblock team explain the logic beyond the protocol here: 

Chatting with the Dr @TTrevethan about why to build lightning latch on @mercurylayer #bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6

— Nicholas Gregory (@gregory_nico) March 15, 2024

And for a more technical explanation, here: 

Going through the technicals of how lightning latch will work with @TTrevethan on @mercurylayer #bitcoin #layer2 pic.twitter.com/aQIcjh2ukq

— Nicholas Gregory (@gregory_nico) March 16, 2024

Source link

Relai, the Swiss-based Bitcoin app with a self-custody wallet, has announced a new partnership with Blockstream and Breez to integrate the Lightning Network into its platform, benefiting over 100,000 European users, according to a press release sent to Bitcoin Magazine.

The Lightning Network offers a scalable solution to facilitate fast and low-cost transactions, making Bitcoin more suitable for everyday use. By leveraging Lightning, Relai aims to streamline Bitcoin payments for its growing user base, empowering them to send and receive bitcoin directly to their wallets in a self-custodial manner.

“Bitcoin is sound money. Lightning is the future of Bitcoin,” said Relai CEO Julian Liniger. “It’s how money will be moved around the world in the 21st century. That’s why Lightning is a strategic focus of Relai and will be integral to our mission of bringing BTC to millions of people quickly, easily, and securely!”

Partnering with industry giants Blockstream and Breez, Relai aims to ensure seamless integration and optimal user experience. Blockstream’s Greenlight cloud nodes and Breez SDK’s Lightning Service Providers (LSPs) enable Relai to offer Lightning’s benefits while maintaining non-custodial control over users’ funds.

The integration of Lightning into Relai’s platform is just the beginning of its product expansion and European expansion plans, according to the release. Relai aims to obtain the MiCA license to extend its services throughout Europe, marking a big step towards its goal of making Bitcoin accessible to millions of users across the continent.

Source link

“Bitcoin is central to our club’s strategy,” stated Botev owner Anton Zingarevich. “We’re inspired by the global success stories of Bitcoin adoption and are excited to bring this innovation to Botev, our fans, and the city of Plovdiv. JAN3’s cutting-edge tools are instrumental in this journey.”

This collaboration introduces innovative measures to integrate Bitcoin into the club’s operations and engage with its fan base. The AQUA Wallet, developed by JAN3, also introduces “Botev Mode,” aiming to make transactions more accessible and efficient for fans and the local community.

JAN3 told Bitcoin Magazine that with the integration of their AQUA wallet, the idea is for the club to introduce discounts or even a cashback program for paying in bitcoin, and that “the club will also aim to educate Bulgarian fans that take an interest in Bitcoin, teaching them how to use it not only for team purchases but also integrate in their daily lives.”

As part of the partnership, Botev Plovdiv’s team jerseys will feature JAN3’s logo. The integration of the AQUA wallet into the club’s ecosystem marks a significant milestone in bridging the gap between professional sports and Bitcoin.

As part of the partnership, Botev Plovdiv’s team jerseys will feature JAN3’s logo. The integration of the AQUA wallet into the club’s ecosystem marks another milestone in bridging the gap between professional sports and Bitcoin.

“Very few things in life are as universal as football and Bitcoin,” commented JAN3 CEO Samson Mow. “With this partnership we hope to bring Bitcoin closer to football, and the billions of football fans around the world closer to Bitcoin. We have already seen what Bitcoin can do for companies and countries, now imagine what it can do for your favorite team.”

This partnership between Botev Plovdiv FC and JAN3 sets the stage for more pioneering Bitcoin-focused initiatives, solidifying the club’s status as a beacon for Bitcoin adoption and achieving greater success in UEFA competitions.

Source link

Over two hundred bitcoiners descended on Uvita from January 18th – 20th which is a popular seaside spot in Costa Rica. The Bitcoin Freedom Festival was billed as a spiritual gathering for those who celebrate freedom money, nature and sovereignty. What many bitcoiners are still discovering about this beautiful place along the southern Pacific coast is that Uvita and Dominical, {the town 18 km north} are the region known as Bitcoin Jungle.

One Of A Kind Bitcoin Festival

The Bitcoin Freedom Festival was held at The Awake Center in Uvita. When you arrive at the appropriately named Awake Center for the festival you quickly realize this is NOT going to be like any other conference you’ve experienced. [Note: It reminded me of attending my first Slow Money Gathering in Boulder, Colorado in 2013 where they closed the conference using a Quaker style practice of silent meditation. Quakers gather in the silence and wait expectantly to come into the presence of the Divine and to be guided by the still, small voice by which God speaks to us from within. During the silence, anyone may feel moved to offer a simple spoken message (vocal ministry) that is inspired by this holy encounter.]

There were three outside covered pavilions where the speakers were featured with the most striking one being a round structure [the Shala] which on Sundays serves as a place for ecstatic dance. The Shala is more reminiscent of a buddhist temple than a conference site. The heart of the grounds was the cafeteria [The Cora] which nourished its visitors and where a small sign at the entrance in very small lettering that only those fully present would notice was the sign “Be, Don’t Become.” The head chef was gracious and very proud of her role in feeding people all organic and vegan meals. For those who consider high quality food to be medicine she seemed to take delight when I said “You and your team are the festival’s primary health care workers on premises.” If this were anything besides a gathering of bitcoiners that would have been the only food offered BUT alas there was also generous portions of beef being served by an outside vendor in another part of the property for the carnivores. This festival also had a place on the AWAKE grounds but NOT INSIDE FESTIVAL BOUNDARIES where merchants and vendors who accept bitcoin could have a booth and sell to festival attendees and the public at large.

To give you some idea how unique this event was, consider this: When was the last time you attended a Bitcoin gathering where shoes came off in the meeting places such as the Cora and the Shala AND where many of the event organizers were barefoot all three days? Oh, with a river bordering the property? If your goal is to get in touch with and be part of nature this was easy to do. If your goal was an air conditioned corporate event this was decidedly NOT for you.

An Incomparable Country Meets Incomparable Money

It’s helpful to understand some of Costa Rica’s cultural history as well in understanding the event. For example, Costa Rica was way ahead of its time in 2002 by embedding “pax natura” into their constitution. Pax natura means peace with nature. I’m not aware of another country with greater care for and love of nature, a culture that avoids waste, a culture that produces most of what it needs locally [including power] and has no standing army. Costa Rica has always remained a neutral country and never engaged in fighting between nations or tribes in Central America which makes it rare. And of course the greeting “Pura Vida” is the perfect expression that you will hear often when you visit. The phrase itself has many shades of meaning.

What prompted the wonderful people behind Bitcoin Jungle to sponsor this festival? They wanted to demonstrate to the local community [Uvita and Dominical] that many bitcoiners would be drawn to the area. By the last day of the festival one of the organizers kept hearing feedback from the local shopkeepers saying “you were right.” We met with one of the merchants at the local Bahia Farmers Market the Wednesday following the conference and she said her business was up 80% because of the conference. She had done so well since signing up for bitcoin 2 years ago that the merchant in the next booth started asking her how she can accept bitcoin. [Wallet tips: In addition to being able to use the Bitcoin Jungle App, the Phoenix wallet worked as did Wallet of Satoshi and Strike. The Muun wallet will work but in the high fee environment you might only use it for purchases of $100 or more. I used my Muun wallet to pay for our lodging and there were a surprising number of places that accepted bitcoin. Nearly every place we went during a two week trip accepted bitcoin using the Bitcoin Jungle App. The beauty of the Bitcoin Jungle App is it lets the user hold bitcoin and use the Costa Rican payment system Sinpe which is widely used in Costa Rica.

Connect With Self So You Can Connect With Others

It’s difficult to capture in words the serenity of the venue. Even so, the true heart of the venue is the river which defines the southern boundary of the property. Since the conference was held during the dry season the river had lots of exposed rock that for those who are ambitious can rock hop to the ocean several kilometers away. Many conversations were held and friendships formed by festival goers cooling off in the river because all venues were outdoors and covered but not air conditioned. Since January is the dry season in Costa Rica it is hot and the river is the place to cool off and connect. The Awake owner indicated he has plans for a cold plunge but it had not been set up in time for the festival.

If you live or work in a place with winter or just drab cloudy cold weather this entire region will warm your body and soul from the inside out. You will literally feel the stress melt away if you allow yourself to slow down. In this age of too many screens, too many distractions, too much insanity this place and the festival is just what the doctor ordered. There were meditation sessions and breath work and many mindfulness programs that focus on connection with self which, in this author’s opinion, is the most important connection. FULL STOP. If we don’t enjoy a strong connection to Self, there is little chance we will enjoy our connection to others.

Many bitcoiners have made a pilgrimage to El Salvador since bitcoin was made legal tender there in September 2021. Give yourself a huge gift and check out its Central American neighbor. You will find Bitcoin Jungle to be a deeply spiritual region that resides in a country and a people who are intimately in touch with nature. Due to the hard work of the Bitcoin Jungle Team, many area merchants have embraced the bottom up adoption of Lightning. It seems only fitting that such a deeply spiritual place would also adopt a deeply spiritual form of money. Pura Vida. 

This is a guest post by Mark Maraia. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Source link

Today Breez announces FiatLink, an open API standard for the integration of on and off ramps directly inside of Lightning wallets and applications. Currently there are many issues with seamless integration of Bitcoin to fiat exchanges inside of applications, chief among them being lack of Lightning support by many brokerages. In addition to that, each brokerage service in the market builds proprietary APIs for integration with their services, increasing the overhead of integration of multiple options by application and wallet developers. Breez SDK’s support for the FiatLink API can facilitate a single solution to both problems.

FiatLink, as an open interface standard, would also allow seamless integration of multiple brokerage options inside a Lightning application or wallet. Rather than have to independently integrate each option’s individual API, any brokerage service that has integrated FiatLink would be usable within an application with no extra development overhead. This can help foster an interoperable ecosystem of multiple brokers and multiple applications all seeking the optimal price point in order matching between users needing to acquire fiat or Bitcoin. Swiss Bitcoin operations, such as Relai and Pocket Bitcoin, were consulted in tailoring the API design to meet the needs of existing brokerage services.

Multiple payment options (SEPA, credit cards, and bank transfers) are supported. API providers allow users to request price and cost estimates, final quotes, and then finally confirm a specific order quote and finalize it by inputting their payment information. In Switzerland, users are able to make transactions up to 1000 CHF (Swiss Franc) in value per transaction between Swiss brokerages and regulated non-Swiss banks without requiring additional KYC beyond the payment method.

Withdrawals from a brokerage service to the users wallet is processed through LNURL-Withdraw. This is a function in the LNURL protocol that allows a static QR code to be saved and scanned by the user at their leisure, negotiating in the background over HTTP providing an actual Lighting invoice to receive their Bitcoin. It allows an optional on-chain address to be included to facilitate withdrawal on-chain if it fails to process over Lightning for any reason.

The API does support Address Ownership Proof Protocol (AOPP) required by some jurisdictions under the Travel Rule, but in the case of Lightning wallet and applications can generate a random Lightning node pubkey to use for a single withdrawal.

FiatLink, if widely adopted, could offer a competitive and streamlined solution to integrating fiat to Bitcoin transfers for wallet and application developers to integrate. 

Source link

CrowdHealth, a crowdfunding platform for paying medical experiences in lieu of an insurance policy, is integrating Lightning payments with Breez’s Lightning SDK. The United States spends more than twice the average amount of money on healthcare in comparison to other developed nations in a similar economic situation. Medical costs are one of the leading causes of bankruptcy in the United States. It is not a secret that the medical system in the US has its issues.

The CrowdHealth model is based on offering an alternative to the conventional insurance policy at a cheaper price point. For a monthly membership fee of $50 a month, far lower than most insurance plans, CrowdHealth will negotiate medical bills to get the cheapest price possible, handle locating care providers and managing bills, discounted prescriptions on drugs, access to their member crowdfunding service, and more.

The crowdfunding aspect is the core distinguishing feature of the platform. Instead of charging a proper premium to create an insurance fund to draw from for paying claims, users of the platform contribute their monthly fee for the bill negotiation and other features directly from Crowdheatlh, and depend on voluntary crowdfunding from other members in order to meet the funding requirements for actually paying medical expenses. The idea, which seems to be working for its current 5000 member user base, is that people will pay it forward to assist others in the network with their expenses under the hope that those people will pay it back in future if they ever need to cover an unexpected expense.

Prior to Breez integration, the company had been functioning over traditional fiat payment rails, and while this has successfully worked to move funds between members, it introduces two main overheads that are fundamentally not addressable on these rails.

Firstly, the payment fees. A bank wire transfer could easily reach $20-30 for a single transfer, which eats into the donated funds that could be going to the member’s medical expenses. It also introduces an implicit minimum amount: If a wire is needed to transfer the money, will someone pay a $20 fee to donate $2 to someone’s bill? Lightning can improve this situation drastically, with mere pennies in transfer fees for any amount the network is capable of transferring within liquidity limitation.

Secondly, the time required for payment settlement. Bank transfers can take days or even weeks to settle under some circumstances. If a medical procedure is needed urgently, this settlement delay could actually cause physical harm to members if the care provider requires payment up front or shortly after a procedure done on credit. Lightning again helps, settling payments with complete finality in seconds.

Through their Lightning Integration using Breez SDK, an already innovative new business model can streamline its costs and potentially improve the scalability of its members crowdfunding each other’s medical expenses. 

Source link

Lightning is doomed. High fees from Ordinals have killed all hope of scaling Bitcoin non-custodially, there is no chance at all that people will be able to cost effectively open channels or enforce hung payments on-chain when necessary. It’s all over, pack it all up guys. Time to start shopping around and deciding whether Coinbase or Cashapp is a better platform for all of our Bitcoin needs now that we can’t afford to do it directly on-chain in a high fee environment.

It was fun while it lasted. We’ll always have the pixelated dick pics on the Lightning art site, the Lightning torch meme where everyone was scared to send it to people in countries the state told us is full of nothing but bad people, we’ll still have the zapping sats from custodial account to custodial account. Into the era of walled gardens we go!

If you took any of that seriously on any level go look at yourself in the mirror, and then give yourself a good hard slap in the face.

Clearing The Gaslighting Fumes

The original Lightning Network whitepaper specifically defined in the conclusion to the paper that for 7 billion people to be able to open two channels a year Bitcoin would require 133 MB blocks.

There is an entire section of the whitepaper called “Risks” (Section 9), that spells out all of the major problems people think means Lightning is “doooooooooomed” because of high fees. The first section of the paper discusses timelock windows. “Improper Timelocks.” This is essentially the dynamic of fee rates versus confirmation time that has become a large concern lately. When you route a payment over the network, you define a success path based on a hashlock preimage, and a clawback path based on the refund timelock window. If fees get higher, that timelock window needs to be longer to guarantee that a preimage spend (the transaction succeeded) doesn’t fail to confirm before a refund transaction becomes spendable.

I.e. if you have to confirm a successful payment on-chain the timelock on the refund path has to be long enough that you can confirm the successful payment path before your channel counterparty can claim the funds through the refund path. How long that timelock window has to be increases the higher feerates get, because the transaction fee decided ahead of time for pre-signed channel closure transactions can be too low to confirm as fast as you expected when you signed them.

Many people are freaking out and losing their shit over this dynamic as if it is some new realization, and it spells the doom of the Lightning Network. This was literally described as a risk in the original whitepaper specifying the first version of the Lightning protocol. It explicitly even described the opportunity cost tradeoff from an economic point of view: “There is a trade-off between longer timelocks and the time-value of money.”

The next section is called “Forced Expiration Spam.” It describes the general concept of the Flood and Loot Attack. An adversary opening a large number of channels and closing them all at once on-chain, specifically to take advantage of the fact that if the feerates got too high refund transactions could have a chance at double-spending success path transactions if something needed to be enforced on-chain. If you have a bunch of channels open with payments in mid-flight, and you close them all at once and drive fees up high enough, then every channel counterparty who has to confirm a successful payment on-chain could find themselves in a doublespend race if the fees are driven up high enough to let the timemlock transaction become valid before the successful one with the preimage is confirmed.

If you have enough channels open, and drive fees up high enough, you can profit from this. It was literally described in the whitepaper as an architectural concern. Depending on which version of the paper you count, this class of attack was described in 2015-2016. It wasn’t formally modeled and introduced into the news cycle of this space until 2020.

The whitepaper described data loss, the situation of losing the pre-signed closure transactions and penalty keys for old states that would allow a malicious channel counterparty to steal your funds if they were aware of this. It brought up the situation of being incapable of broadcasting a penalty transaction, and the potential for watchtowers to solve this as a third party being paid to watch the blockchain and submit those transactions on your behalf. It literally described miners censoring channel penalty transactions as a risk, and suggested miner anonymity (and implicitly decentralization) as the mitigation for that risk.

But this is all new information. The Lightning Network is doomed to failure because no one saw any of these problems coming!!!!

The Blockchain You Idiots

Well, I guess we can just admit historical context is lost. Reason is lost. Logic and rationality is lost. We are in a reality where we are going to pretend like historical warnings don’t exist, no one ever pointed out obvious problems destined to manifest in the future, and this is all just totally uncharted territory where no one ever thought about how things would play out.

What is the title of Section 9.6? Oh: Inability to Make Necessary Soft-Forks.

The original whitepaper explicitly spelled out the inability to coordinate soft forks as a risk to the success of the Lightning Network. Are you surprised? Have you never read any of this before? Personally I’m getting deja vu.

I remember years and years ago, a large contingent of Bitcoiners screaming that the blockchain itself was hitting scaling limits, that it would fail unless we fundamentally altered the entire nature of the decentralization trade offs of the system. Blockchains were fundamentally useless if people couldn’t directly submit all of their transactions on-chain and have them cost effectively confirmed.

The entire foundation of the Bitcoin ecosystem was rocked to its core when people started arguing over the cost effectiveness of the blockchain at scale, that was literally the entire cause of the blocksize war. What was at the core of this disruption? People’s expectations of what role the blockchain would play in the puzzle of Bitcoin’s evolving ecosystem. Everyone is going to buy their coffee on-chain at a cost-effective feerate, or Bitcoin is a total failure.

Everyone with that mentality just completely misjudged the entire situation. They were trying to stuff a square peg into a round hole. It’s the exact same thing with Lighting.

Square Peg, Round Hole

The blockchain was sorely misjudged, it was really just a place to put channel openings and closings, not a place to buy your coffee. There’s no real chance that people misjudged Lightning though, that is surely the place to put your coffee payments. No one could possibly have misjudged that this time. See how silly that sounds when you put it like that in proper context? Lightning has issues with enforcing payments on-chain; if the value of the payment is less than the fee to submit the transaction to the chain, this is a problem. It makes no economic sense to try to enforce it on-chain. This was a very well known problem. It’s essentially the exact same problem of low value payments happening directly on-chain, except in the optimistic case things just work because people cooperate off-chain. But when they don’t cooperate, there are problems.

This problem was so well known that there was actually a good deal of debate years ago about a solution to it with different trade-offs, packetized payments. If an HTLC is too small to be able to enforce trustlessly on-chain, you can stream a payment sat by sat (or larger chunks of sats) in a trusted manner, and stop streaming and pick another route if someone in a hop decides they’re going to steal a sat from you. The idea is that while it is a trusted payment routing mechanism, you can only lose a few sats to an attacker who steals a tiny piece of your payment, and if someone steals from you while routing a payment you just never route through those nodes again. The citation above is from 2019, but this idea was discussed earlier than that.

Lightning has a problem! (And also a solution to that problem most people reading probably never heard about). All of these issues people seem to think means the sky is falling are issues well understood from the very beginning of Lightning. This begs a question: were we wrong again?

Not wrong in the sense that Lightning is a doomed dead end, but wrong in the sense that Lightning is not going to be used long term in the way we thought it was initially, just like the blockchain itself. We already see Lightning dominated by custodial applications, and people are working on deploying things specifically designed to sit on top of Lighting. Chaumian ecash mints, Uncle Jim setups like LNBits where people are given a custodial account on someone’s Lightning node. We even have proposals like Ark being built out in the proof-of-concept phase on Liquid, which can interact atomically with Lightning payments.

What if Lightning isn’t going to be the killer protocol that consumers directly interact with in order to make their payments online? What if, just like the blockchain itself, it simply winds up being a piece of a settlement layer that other things are built on top of?

Would that be the end of the world? Would that be a failure of Lightning? I would argue absolutely not. From the very beginning of development on Lightning it was incredibly clear what its scaling limitation would be. The whitepaper literally brings up the issue of not getting support for softforks needed in the future as a limitation of Lightning’s potential scalability.

Lightning is proving definitively right now that it can function as a layer for interactivity between different custodians, and that it works smoothly and very effectively for that. There is no reason at all Lightning cannot function as a similar connectivity layer for other layer twos that have superior trust models than a explicit custodian. If channels are not something individuals can cost effectively have for their daily spending activity, that doesn’t mean they are not cost effective for LSPs who run new protocols in addition to Lightning to link between each other, allowing their users to interact with each other. Arks, Statechains, and whatever new ideas people develop over the coming years.

It can be a translator layer for other systems that scale the end users ability to onboard and transact on those layers, exactly like we wound up realizing the blockchain would have to be. And there is nothing wrong with that. 

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Source link

So a lot of noise has been made around the Lightning vulnerability recently disclosed by Antoine Riard. Many people are claiming the sky is falling, that Lightning is fundamentally broken, and nothing could be further from the truth. I think part of the problem is that people don’t really understand how this vulnerability works, firstly, and secondly many people don’t understand how this individual vulnerability overlaps with other known issues on the Lightning Network that have known solutions.

So first, let’s go through and try to understand the vulnerability itself. When a Lightning payment is routed across the network, one thing that is key to understand is how the timelocks for refunding a failed payment work. The hop closest to the receiver has a timelock of ‘x’, and every hop going back to the sender has one of ‘x+1’, ‘x+2’, and so on. The timelocks get progressively longer as you go each hop from the receiver back towards the sender. The reason for this is that if a payment reaches the receiver, but some problem stops the preimage from propagating all the way back to the sender, the hop where it stopped has time to enforce it on-chain, and put the preimage there that all preceding hops need to confirm the payment. Otherwise someone in the middle, where the failure happens, could have their outgoing hop claim the funds with the preimage, and the hop that forwarded it to them claim it with their refund path, and leave that person in the middle shit out of luck having lost funds.

The Replacement Cycling Attack is a complicated way to try and accomplish exactly that undesired outcome, the target node losing money by having the outgoing hop claim the funds with a success transaction, and the incoming hop claiming funds through the refund transaction. This necessitates stalling out the victim node, and preventing them from seeing the preimage in the success transaction on one side until after the timelock expires on the other side, so they can claim the refund there.

This requires a very targeted and complicated game of manipulating the victim’s mempool. Let’s look at the actual transaction structure involved here. You have the commitment transaction, which is the main transaction representing the Lightning channel state. It has an output for each side of the channel representing funds completely under the control of one member or the other, and outputs for each HTLC in the process of being routed. These outputs are the ones we are concerned with. Each HTLC output can be spent either immediately at any time with the preimage from the receiver, or after the timelock expires on the refund.

The attack requires that a malicious party, or two conspiring parties, have a channel on both sides of the victims node routing a payment. So Bob, the victim, has a channel with Alice and Carol, the attackers, and payment routed from Carol to Bob to Alice. Now remember, the timelock refund path between Alice and Bob will expire and become valid before the refund between Carol and Bob.

The attackers route a payment through Bob, and then Alice will refuse to send Bob the preimage to finalize the payment when she receives it. What Bob will do now is wait until the timelock window expires between himself and Alice, and go to broadcast the channel commitment transaction and refund transaction to get it confirmed before the timelock window expires. What Alice will do is then go to spend the preimage transaction to claim the funds with an output unrelated to the channel, and right afterwards doublespend the second input in the preimage success transaction. The goal here is to evict Bob’s timeout transaction from the mempool, but also evict the preimage success transaction so Bob doesn’t see it. If he does, he will learn the preimage and can simply claim the funds in his channel with Carol before her timeout transaction is valid to spend.

Alice and Carol have to do this on a consistent basis, everytime Bob rebroadcasts his timeout transaction with Alice, until the blockheight passes where Carol’s timeout transaction is valid. Then they can submit the success transaction on Alice’s side, and the timeout transaction on Carol’s side, and leave Bob holding the bag having lost the value of the payment he was routing.

The problem with this is two fold. Firstly, the victim’s Bitcoin Core node must be specifically targeted to ensure that at no time does the preimage success transaction propagate into their mempool where their Lightning node can acquire the preimage. Secondly, if the second transaction Alice uses to evict the preimage transaction is confirmed, Alice incurs a cost (remember, the idea is to replace the timeout transaction with the preimage, so that is evicted from the mempool, then replace the preimage transaction with the second one double-spending the additional input in the preimage transaction). That means every time Bob re-broadcasts his timeout transaction, Alice has to pay a higher fee to re-evict it, and when that is confirmed she actually incurs a cost.

So Bob can force Alice to incur a big cost simply by regularly rebroadcasting his timeout transaction with a higher fee, meaning if the payment HTLC output is not worth significantly more than the fees Alice could incur, the attack isn’t economically worthwhile to pull off. It would also be possible to prevent the attack completely by changing how HTLC success and timeout transactions are constructed. By using the SIGHASH_ALL flag, which means the signature commits to the entirety of the transaction and becomes invalid if the tiniest detail (like adding the new input in the preimage transaction required for this attack) is changed. This wouldn’t work with current version of Lightning channels using anchor outputs, but it would solve the issue entirely. Peter Todd has also proposed a new consensus feature that would entirely solve the issue, essentially a reverse timelock, where the transaction would become invalid after a certain time or blockheight instead of becoming valid after. Going that far however is not necessary in my opinion.

Simply rebroadcasting your transaction regularly with a slight fee bump is a massive mitigation of the attack, but there are also numerous dynamics that just make it not a serious issue regardless. First, if you aren’t a routing node, this isn’t really a serious issue. So most end users are safe from this attack. Secondly, there are many reasons why nodes do not allow any random person to open channels to them. Large nodes are very selective about who they peer with, as random channels not managed efficiently or professionally have a cost in the form of sunk or wasted capital in unused channels. So any large node that would make a juicy target for this attack is not trivial to even get connected with in the first place, let alone connect to them with multiple channels to pull off the attack in the first place. Lastly, as I’ve written about in the past, other unrelated attacks possible on the network are already necessitating filters and restrictions in how nodes choose to handle HTLCs they could forward. I.e. limits on the size of payments they will forward, how many they will allow at any given time, etc. So even if you can open a channel with a node worth attacking, as the network evolves there will be more thought through criteria and filters for deciding whether to even forward a payment in the first place.

Overall, this is a legitimate issue and possible attack, but both in terms of direct mitigations, and how the attack will interact with solutions to other issues over the long term, this is not an unsolvable problem. It is a legitimate issue, and dismissing it as purely FUD is not an accurate reaction, but to claim the sky is falling and the Lightning Network as a protocol is doomed is far overblowing the issue.

Time will march on, we will run into problems, and we will fix those problems as they come. Like we always have. 

Source link