Lightning This Week #666,209
Bitcoin-infused Counter Strike, trampoline routing nodes, revamped LND documentation, and new techniques for anti-UTXO probing on LN dual-funded channels.
Hello and welcome to LTW. To start things off on a happy note, the team behind MintGox ESports tournament have released the details for the next event on Sunday January 31st. A total prize pool of 10 million satoshis are up for grabs for those willing to be challenged in matches of CS:GO, Bitcoin Rally, BBH and Turbo84.
The team was interviewed on the latest Swan Live Lounge podcast and released a video that explains the thinking behind MintGox and how it is different from any conventional ESports tournaments. Join MintGox and witness the future of Bitcoin Gaming.
Infusing Counter Strike with Bitcoin
If you’ve been living under a rock you may have missed the announcement, but the ZEBEDEE team have officially infused Bitcoin into Counter Strike: Global Offensive. Yes — that Counter Strike!
The purest form of global, digital economies are video games, but they lack a purely global and digital form of transactional value. So why not take an existing popular game and integrate Bitcoin as the value transfer protocol. The question we wanted to answer is: Does this add a new dimension to the gameplay that dramatically increases enjoyment and engagement?
On December 27, 2020, [ZEBEDEE] demonstrated this concept live at MintGox in front of an online audience of over 5,000 viewers. We successfully infused Bitcoin into Counter-Strike: Global Offensive (CS:GO), a multiplayer first-person shooter video game with 20 million monthly active users. And with that, the first public reveal of ZEBEDEE’s newest product, Infuse, will bring Bitcoin to the world’s most popular games.
With the power of Bitcoin’s Lightning Network, ZEBEDEE’s Infuse product will allow any CS:GO player to play Counter Strike and win sats against their opponents. Public release is expected in Q1 of 2021 with lots of servers ready to play. Get your Lightning wallets ready. To see Infused CS:GO live, make sure to participate in the next MintGox tournament.
Bitcoin Magazine Article: Bitcoin’s Killer Application: Skin In The Game
What is Trampoline Routing?
When Alice wants to pay Bob over Lightning, Alice’s node must first calculate a liquid route to send that payment along, such that it successfully arrives to Bob’s node. Recently Bastien Teinturier from ACINQ posted an updated specification of the Trampoline Routing mechanism the team has been using for over a year now with their Phoenix mobile wallet users.
Trampoline routing in its essence allows a spender (Alice) to pay a receiver (Bob) without needing to calculate a route between the nodes. Instead Alice can simply route the payment to a trampoline node that is then able to calculate the last part of the route to reach its destination. One can easily visualize how a set of trampoline routing nodes can be very powerful when used in tandem. If one trampoline node doesn’t know the last part of the route to reach the receiver, it can send that payment to another trampoline node which has a different set of peers and could be connected to the receiver. When a payment is sent to a trampoline node, we call that a bounce.
As mentioned before, ACINQ is using a trampoline routing node setup to handle incoming payments to users of their Phoenix mobile wallet. Since Lightning nodes need to be online in order to receive payments, this is super useful for mobile Lightning clients which are offline most of the time. Additionally when a node is offline for long periods of time, its understanding of the network graph/gossip is outdated, so route calculations could/would fail. Why calculate the route yourself, when you can let a trampoline routing node do that job for you?
This proposal allows nodes running on constrained devices to sync only a small portion of the network and leverage trampoline nodes to calculate the missing parts of the payment route while providing the same privacy as fully source-routed payments.
One obvious downside of relying on the current implementation of trampoline routing nodes to route your payment is loss of privacy. In order to route the payment to its destination, the trampoline node must know the details of that destination node. When running the trampoline node that backs the users of the Phoenix wallet, ACINQ is able to see the destination of all its users’ payments. The updated specification proposes a solution to this privacy leak by relying on onion-wrapper trampoline route details such that the trampoline node is unable to learn the node identifier for both the spender and receiver at any one time.
If you’d like to learn more about Trampoline Routing, check out Bitcoin Optech’s glossary.
Lightning-Dev Mailing List: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002928.html
LN RFC Specification: https://github.com/lightningnetwork/lightning-rfc/pull/829
New LND Documentation
Most software engineers would agree that what makes a great developer product is its documentation. With the recent releases of Pool, Loop, Lightning Terminal, and Faraday it was time for the Lightning Labs team to show some love for its documentation portal.
As a provider of software development tools for Bitcoin and Lightning Network, I’m thrilled to be able to point newcomers to this guide and have them choose their desired path, and level of complexity. With detailed guides for beginners, intermediate, and advanced users, the Builder’s Guide to the LND Galaxy has something for everyone.
Builder's Guide to the LND Galaxy: https://docs.lightning.engineering/
Anti-UTXO probing on dual-funded LN channels
A common issue when starting your Lightning Network trajectory and running your own node is opening and managing LN channels. Not only are operators encouraged to maintain liquid balanced channels, but they must also ensure their node is always reachable online so that payments can be successfully routed through those channels. Right now, when opening LN channels, the funds that get deployed are only coming from the side of the initiating node. This means funds can only be sent from the initiating node (as all liquidity is on their side of the channel), and effectively blocks the initiating node from receiving any payments on that channel.
In a not-so-distant future, all Lightning implementations aim to support dual-funding channel functionality. This means there will be support for the ability to open a new channel between two nodes where the initial funds are coming from both the node initiating the request and the node receiving the channel-open request. This will allow payments to be sent and received by both sides as soon as the channel is opened.
That said, a major concern with dual-funding channels is UTXO probing:
Before the initiator can sign the dual funding transaction, they need the identities (outpoints) of all of the UTXOs the other node wants to add to the channel. This creates the risk that an abuser will attempt to initiate dual-funded channels with many different users, learn their UTXOs, and then refuse to sign the funding transaction — harming those users’ privacy at no cost to the abuser.
An initial idea in 2016 was Proof of Discreet Log Equivalency (or PoDLE for short), first proposed by Gregory Maxwell for the JoinMarket protocol. It allows an initiating node (Alice) to commit to a UTXO in a way that prevents anyone from identifying that UTXO — Alice can show proof of owning the UTXO without revealing the details of the UTXO. Another proposal was posted by Darosior in the beginning of 2020 which dealt with interactively creating the dual-funding transaction using a chain construction through half-signed sighash_single & sighash_anyonecanpay transactions.
Recently we saw Lloyd Fournier post a new proposal to the Lightning-Dev mailing list where he expands on these previous ideas. Fournier proposes a simpler version of the half-signed implementation that is just as effective. In the new proposal the initiating node (Alice) creates and signs, but does not broadcast, a valid transaction that spends their UTXO back to themselves. This signed transaction is given to the receiving node (Bob) and can be verified as a valid transaction without giving details about the UTXO used. This is done as a token of good faith — if Alice fails to actually sign the dual-funding-channel transaction later on, Bob can simply broadcast the good faith transaction which forces Alice to pay an onchain fee, thus incurring costs and disincentivizing this behavior.
The idea is to adapt this protocol for Lightning Network in order to prevent attackers from learning which available UTXOs are controlled by Lightning node users.
Original PoDLE post for JoinMarket: https://joinmarket.me/blog/blog/poodle/
Lightning-Dev Mailing List: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-January/002929.html
Things I Would Share This Week
Eclair v0.5.0 — In LTW #662,816 we covered Eclair in Enterprise Environments discussing the new architectural capabilities of the Eclair node software. The ACINQ team has since then posted version v0.5.0 of the implementation which includes this multi-node architecture, as well as many other goodies.
LND v0.12 rc5 — Lightning Labs team just posted the latest Release Candidate for the LND software implementation. Node operators are encouraged to help test and find bugs.
Bitcoin Core v0.21.0 — The latest version of Bitcoin Core was posted earlier this week. While there are lots of goodies to read from the changelog, I’m highlighing this because, you know, 21M BTC and version 0.21. It’s a must.
That's all for Lightning This Week - see you next time!