This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and host of a tech-oriented Bitcoin podcast.
Channel jamming is one of the most threatening problems with the Lightning Network. This provides an open mechanism for denial of service attack nodes in the network to prevent the route, losing money when liquidity is locked and unable to proceed with payments that will incur costs. Attackers can route payments through nodes other than themselves, and refuse to complete the payment. This makes it pointless for liquidity to proceed with further payments until the hashed time contract (HTLC) expires and payments are returned.
Last month, Lightning developer Antoine Riard proposed an official specification for a solution to this problem. In August, Riard and Gleb Naumenko published research on the common problem itself, as well as some solutions that can be used to reduce or overcome it. One of the proposed solutions is a form of anonymous credentials that nodes can use to build a reputation scoring system for users that directs payments through them without having to dox or associate the reputation with a static identifier that would affect people’s privacy. This solution has now become a formal protocol proposal made by Riard last month.
In Channel Jamming Mitigation Proposal
The core of the idea is Chaumian’s ecash token. These are centralized tokens issued by the mint authorities in a way that prevents token issuance from being linked to later token redemptions. This is done by signing the token in a blind way, allowing the recipient of the token to remove the sign without revoking the signature. The issuer can then verify that it is a valid token without being able to link the token when it is issued.
The proposal suggests using this Chaumian token, issued by each routing node in the network, as a form of proof of reputation. When routing a payment, Chaumian ecash tokens issued by each node in the payment hop will be wrapped in an onion bundle for that node along the payment hop. The token unit will represent the value of the HTLC allowed as well as the key period of the refund period. Before proceeding with HTLC, each node will verify that the token inserted into the onion blob is valid and has never been redeemed before, only proceeding with HTLC if the condition is true.
If HTLC settles successfully with the revealed preimage, then every node along the payment path signs and includes the newly issued Chaumian token to return to the sender, together with the HTLC preimage. If the HTLC is not successfully populated, then the routing node “burns” the token by including it in the table of used tokens and does not issue new tokens. This forces the sender to obtain new tokens from the node in order to repay. The whole concept is that the jamming attack always fails to settle, so in this scheme, this token issued by each node that you route through will be burned if you do a jamming attack and make it cost to acquire another to do it again. Currently, jamming attacks have no cost except time, so this will increase the economic cost.
So, it’s time to discuss the elephant in the room: how to bootstrap the issuance and circulation of these tokens in the network? Every node you want to pass through needs a token issued. Solution: pay for them. Another proposed solution to the problem of channel jamming is upfront fees, that is, charging a fee to try a payment route, regardless of whether it is successful or not. So, even a failed payment will be charged to the sender.
Riard’s proposal is to buy the tokens directly from each node as a one-by-one purchase. From that point, instead of paying an initial fee for each payment, as long as the previous payment is successfully completed, you will be given back a “route token” that will allow the next proposed payment to be routed at no cost. In this way, successful payments only pay the actual routing fee, and failed payments only pay up-front fees, preventing a sort of “double fee” for successful payments. At least economically, think of it as a kind of middle compromise between the current situation where failed payments have no fee and only successful payments pay a fee, and a full fee model where all payments pay an upfront fee and successful ones also pay a routing fee.
Takeaways From The Proposal
Personally, I think that direct payment for these tokens in advance could introduce a lot of UX friction in the process of using the Lightning Network. However, I think there is a fairly simple solution to this friction by changing the proposal.
Instead of having to pay each node directly for the previous Chaumian token, the proposal can be hybridized more directly with the up-front fee proposal. If you have a token for the node, then put it in the onion lump, otherwise just pay the fee up front directly in the HTLC proposal and if the payment is successful, you will be issued Chaumian tokens again in proportion to what you did. -front fee is there. This way, instead of having to collect tokens from various nodes in advance, you only acquire them during the initial payment until you have a good collection from various nodes that you use frequently and rarely have to pay fees. from the up front cost to get it.
Another source of potential friction for node operators, and explains the fundamental problem of Chaumian ecash itself. To ensure that tokens are used only once, issuers must maintain a database of all tokens that have been issued. This grows forever, making the search to check the validity of the token more expensive and time-consuming the larger the database. Because of this, Riard proposes that these Chaumian tokens expire periodically, at block heights advertised in each node’s gossip protocol. This means that the sender must periodically repurchase the token, or if the implementation supports it, redeem a new token signed by a new signature key after the previous one has expired.
This would create regular economic costs for payment senders, or require periodic checks to ensure reissuance when old tokens expire. In practice, this can be automated for people running their own Lightning nodes, and for any wallet built on the Lightning service provider (LSP) model, the LSP itself can handle token acquisition and maintenance on behalf of users, handling token provisioning for user payments. However, at the edge, without a full Lightning node or LSP, this can be a nuisance for light wallet users.
I think this proposal can go a long way to reduce channel jamming as an attack vector, especially if the hybrid is more closely related to the basic front cost scheme, and most of the UX friction can be easily handled for LSP users and people who operate their own Lightning nodes. And although the up-front fees provide a high level of friction, it may just prove that Bitcoin UTXO control can be used in lieu of fees to acquire tokens.
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.