This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
Channel jamming is one of the most threatening outstanding problems with the Lightning Network. It presents an open mechanism to denial-of-service attack nodes on the network to prevent them from routing, losing them money while their liquidity is locked up and unable to forward payments that will earn them fees. An attacker can route a payment through other nodes from themselves to themselves, and refuse to finalize the payment. This makes that liquidity useless for forwarding other payments until the hashed timelock contract (HTLC) timelock expires and the payment refunds.
Last month, Lightning developer Antoine Riard proposed a formal specification for a solution to this problem. 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 solve it. One of those proposed solutions was a form of anonymized credentials that nodes could use to build a sort of reputation scoring system for users routing payments through them without having to dox or associate that reputation with a static identifier that would negatively impact peoples’ privacy. This solution has now become the formal protocol proposal made by Riard last month.
Inside The Channel Jamming Mitigation Proposal
The core of the idea is a Chaumian ecash token. These are centralized tokens issued by a mint authority in a way that prevents the issuance of a token from being correlated to the redemption of a token later. This is done by signing a token in a blinded way, allowing the receiver of the token to unblind it without invalidating the signature. The issuer can then verify it is a legitimate token without being able to connect that token to when it was issued.
The proposal suggests using these Chaumian tokens, issued by each routing node on the network, as a form of reputational proof. When routing a payment, a Chaumian ecash token issued by each node in the payment hop would be wrapped up in the onion bundle for that node along the payment. Token units would represent both the value of the HTLC allowed as well as the refund timelock period. Before forwarding the HTLC, each node would verify that the token included in their onion blob is valid and has never been redeemed before, only forwarding the HTLC if both of those conditions are true.
If the HTLC settles successfully with the preimage being revealed, then every node along the payment path signs and includes a newly-issued Chaumian token to be returned back to the sender, along with the HTLC preimage. If the HTLC does not successfully settle, then 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 entire concept is that jamming attacks always fail to settle, so in this scheme, these tokens issued by each node that you route through are burned if you perform a jamming attack and create the cost of acquiring more to do it again. Right now, jamming attacks cost nothing but time, so this would add an economic cost to them.
So, it’s time to discuss the elephant in the room: how do you bootstrap the issuance and circulation of these tokens across the network? Each node that you wish to route through would require a token issued by them. The solution: pay for them. Another proposed solution to the channel jamming issue is up-front fees, i.e., charging a fee to even try to route a payment regardless of whether or not it even succeeds. So, even failed payments would incur a fee for the sender.
Riard’s proposal is to purchase these tokens directly from each node as one-off purchases. From that point forward, instead of paying upfront fees for every payment, as long as the prior payment successfully settled, you would be reissued “routing tokens” that would enable 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 up-front fee, preventing a sort of “double fee” for successful payments. At least economically, think of it as a sort of middleground compromise between the current state of affairs where failed payments cost nothing and only successful payments pay a fee, and a full up-front fee model where all payments pay an up-front fee and successful ones pay a routing fee as well.
Takeaways From The Proposal
Personally, I think this sort of direct payment for tokens ahead of time could introduce a large degree of UX friction into the process of using the Lightning Network. However, I think there is a pretty simple solution for that friction by tweaking the proposal a bit.
Instead of having to specifically pay each node directly for Chaumian tokens ahead of time, the proposal could be hybridized more directly with the up-front fee proposal. If you have tokens for a node, then include those in the onion blob, if not simply pay an up-front fee directly within the HTLC proposal and if the payment settles successfully, you will be issued Chaumian tokens back in proportion to what your up-front fee was. This way, instead of having to collect tokens from many different nodes ahead of time, you simply acquire them over the course of making initial payments until you have a good collection from the different nodes that you use frequently and very rarely have to incur the cost of up-front fees to attain them.
Another potential source of friction is for node operators, and comes down to fundamental issues of Chaumian ecash itself. In order to ensure that a token is only spent once, the issuer needs to maintain a database of all the tokens that have been spent. This grows forever, making lookups to check token validity more and more expensive and time consuming the bigger that database grows. Because of this, Riard proposes having these Chaumian tokens expire periodically, at a block height advertised in the gossip protocol per node. This means that senders need to periodically repurchase these tokens, or if the implementation were to support it, redeem them for new tokens signed by the new signing key after the prior one expires.
This would either place a regular economic cost on the senders of payments, or require them to periodically check in to ensure reissuance when old tokens expire. In practice, this can be automated for people running their own Lightning nodes, and for any wallets built around an Lightning service provider (LSP) model, the LSP itself could actually handle the acquisition and maintenance of tokens on behalf of its users, handling the token provisioning for its users’ payments. On the fringes, however, without a full Lightning node or LSP, this could become a bit of an annoyance for light wallet users.
I think this proposal could actually go a long way to mitigating channel jamming as an attack vector, especially if hybridized a little more tightly with the basic up-front fee scheme, and most of the UX frictions can be handled very easily for LSP users and people who operate their own Lightning nodes. And even if the up front fees do present a high degree of friction, it’s possible that simply proving control of a Bitcoin UTXO could be used in place of actually paying 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.
Shinobi
Source link
