This is an opinion editorial from Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
Channel interference is one of the most threatening pending issues with the Lightning Network. It features an open mechanism for denial of service attack nodes in the network to prevent them from being routed, causing them to lose money while their liquidity is locked up and they are unable to forward payments which will incur fees for them. An attacker can route a payment through other nodes of its own and refuse to finalize the payment. This renders the liquidity useless for forwarding other payments until the hash contract timelock (HTLC) expires and the payment is refunded.
Last month, Lightning developer Antoine Riard proposed a formal specification to address this issue. In August, Riard and Gleb Naumenko published research looking at the general problem itself, as well as a number of different solutions that could be used to mitigate or resolve it. One such proposed solution was a form of anonymous credentials that nodes could use to build a sort of reputation scoring system for users who route payments through them without having to dox or associate that reputation with a static identifier that would negatively affect people’s privacy. This solution has now become the formal protocol proposal made by Riard last month.
Within the channel interference mitigation proposal
The core of the idea is a Chaumian Cash Token. These are centralized tokens issued by a mint authority in a way that prevents a token issuance from being correlated with a subsequent token redemption. This is done by blindly signing a token, allowing the recipient of the token to decrypt the token without invalidating the signature. The issuer can then verify that it is a legitimate token without being able to link that token back to the time it was issued.
The proposal suggests using these Chaumian tokens, issued by each routing node in the network, as a form of reputation proof. When routing a payment, a Chaumian Cash Token issued by each node in the payment hop would be wrapped in the onion bundle for that node throughout the payment. The token units would represent both the value of the allowed HTLC and the redemption time period. Before forwarding the HTLC, each node would verify that the token included in its onion blob is valid and has never been redeemed before, and will only forward the HTLC if both conditions are met.
If the HTLC is successfully resolved and the preimage is revealed, then each node along the payment path signs and includes a newly issued Chaumian token that will be returned to the sender, along with the HTLC preimage. If the HTLC is not resolved correctly, the routing nodes “burn” the token by including it in their spent token table and do not issue a new token. This forces the sender to have to acquire new tokens from those nodes in order to route payments through them again. The whole concept is that jamming attacks always fail, so in this scheme these tokens issued by each node you route through are burned if you do a jamming attack and create the cost of acquiring more to do it again. Right now, jamming attacks cost nothing more than time, so this would add economic cost to them.
So, it’s time to talk about the elephant in the room: how do you start the issuance and circulation of these tokens on the network? Each node you want to route through will require a token issued by them. The solution: pay for them. Another proposed solution to the channel interference problem is upfront fees, that is, charging a fee for even attempting to route a payment, regardless of whether it is successful or not. Therefore, even failed payments would incur a fee to the sender.
Riard’s proposal is to buy these tokens directly from each node as one-time purchases. From then on, instead of paying fees upfront for each payment, as long as the previous payment has been successfully settled, you will be reissued “routing tokens” that allow your next proposed payment to be routed without a fee. This way, successful payments only pay the actual routing fee and failed payments only pay the initial fee, avoiding a kind of “double fee” for successful payments. At least from an economic point of view, think of it as a sort of compromise between the current state of affairs where failed payments cost nothing and only successful payments pay a fee, and a full upfront fee model in which that all payouts pay an initial fee and successful ones also pay a routing fee.
Conclusions of the proposal
Personally, I think this kind of direct payment for tokens up front could introduce a high degree of UX friction into the Lightning Network usage process. However, I think there is a fairly simple solution to that friction by modifying the proposal a bit.
Rather than specifically having to pay each node directly for Chaumian tokens up front, the proposal could be more directly matched to the initial fee proposal. If you have tokens for a node, include them in the onion blob, if not, simply pay an upfront fee directly within the HTLC proposal, and if the payment is settled successfully, the Chaumian tokens will be returned to you in proportion to what what are you doing. -the fee was upfront. This way, instead of having to collect tokens from many different nodes in advance, you just acquire them over the course of initial payments until you have a good collection of the different nodes that you use frequently and very rarely have to incur any the cost. of fees in advance to achieve them.
Another potential source of friction is for node operators, and it boils down to fundamental issues of Chaumian’s own e-money. To ensure that a token is only spent once, the issuer must maintain a database of all tokens that have been spent. This grows forever, making lookups to verify token validity increasingly expensive and time consuming as the database grows. Because of this, Riard proposes that these Chaumian tokens expire periodically, at a block height announced in the gossip protocol per node. This means that senders must periodically repurchase these tokens or, if the implementation supports them, redeem them for new tokens signed by the new signing key after the old one expires.
This would incur a regular financial cost to payment senders, or require them to register periodically to ensure reissue when old tokens expire. In practice, this can be automated for people running their own Lightning nodes, and for any wallet built around a Lightning Service Provider (LSP) model, the LSP itself could handle the acquisition and maintenance of tokens in name of your users, managing the provisioning of tokens for your users’ payments. On the side though, without a full Lightning node or LSP, this could become a hassle for light wallet users.
I think this proposal could actually go a long way towards mitigating channel interference as an attack vector, especially if coupled a bit more closely with the basic upfront fee scheme, and most of the UX friction can be handled very well. easily for LSP users and people running their own Lightning nodes. And even if the initial fees present a high degree of friction, they may simply test control of a Bitcoin UTXO could be used instead of paying fees to acquire tokens.
This is a Shinobi guest post. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
