This opinion editorial is by Shinobi, a self taught educator in Bitcoin space and tech-oriented Bitcoin podcast hosts. Channel jamming is one the most serious problems still to be solved with the Lightning Network. It allows for denial-of service attack nodes to be able to block them from routing, causing them to lose their money and making them unable to send payments that will earn them fees. An attacker can route a payment from themselves to another node and refuse to complete the payment. This renders the liquidity inaccessible for forwarding any other payments until the timelock (HTLC), expires and the payment is refunded. Lightning developer Antoine Riard presented a formal specification last month for a solution. Gleb Naumenko and Riard published research in August that examined the problem itself and suggested a variety of solutions. One of the solutions proposed was anonymized credentials that nodes could use for a reputation scoring system that users can use to route payments through them. Users would not have to dox or associate this reputation with a static ID that would negatively impact their privacy. Riard has now made this proposal as a formal protocol. Inside The Channel Jamming Mitigation PlanThe heart of the idea is a Chaumian-ecash token. These tokens are issued by a mint authority centrally so that they cannot be correlated with the redemption of another token later. This is achieved by blindly signing a token. The receiver can then unblind the token without invalidating the signature. It is then possible for the issuer to verify that it is legitimate without being able connect it to the date it was issued. These Chaumian tokens would be used as reputational proof by each routing node. A Chaumian ecash token would be issued by each node of the payment hop. It would then be wrapped in an onion bundle for each node to facilitate routing the payment. Token units will represent the HTLC allowed value and the refund timelock period. Each node will verify that the token in their onion blob has been valid and not been redeemed before forwarding the HTLC. Only forward the HTLC if both conditions are true. If the HTLC settles with the preimage being disclosed, then each node along the payment pathway signs and includes a newly-issued Chaumian to be returned to the sender along with the HTLC Preimage. If the HTLC fails to settle, the routing nodes “burn” that token and include it in their spent token list. They do not issue a new token. To route payments through those nodes again, the sender will need to purchase new tokens from these nodes. Jamming attacks never settle. This means that tokens issued by nodes you route through are destroyed if you attempt to jamming attack. Jamming attacks are time-consuming, so they would be economically costly. Now it’s time for the big question: How do you bootstrap the circulation and issuance of these tokens throughout the network? Tokens would be required for each node you want to route through. You can pay for them. Another solution to channel jamming is up-front fees. This means that you charge a fee to try to route a payment, regardless of whether it succeeds. Even failed payments would be subject to a fee. Riard proposes to buy these tokens from each node as a one-off purchase. You would then be able to request reissued routing tokens that would allow your next payment to be routed. The routing fee is only paid for successful payments, while the up-front fee is only charged for failed payments. This prevents a double fee for unsuccessful payments. It is a compromise, at least economically. This would be a mix of the current system where unsuccessful payments cost nothing and only successful ones pay a fee and a full up front fee model where all payments pay an upfront fee and successful ones pay routing fees. Personally, this type of direct payment for tokens could cause a lot of friction in the use of the Lightning Network. The proposal could be modified to reduce friction. The proposal could be combined with the up-front fees proposal to make it easier for nodes to pay Chaumian tokens in advance. If you have tokens that you want to use for a particular node, you can include them in the onion blob. If the payment settles successfully you will receive Chaumian tokens back proportionally to your up-front fees. Instead of collecting tokens from multiple nodes at once, you can simply accumulate them over time by making initial payments until you have a good number. You will then be able to make additional payments until you have a decent collection. This will allow you to avoid having to pay up-front fees. Node operators can also be a source of friction. This is due to fundamental issues with Chaumian Ecash. To ensure that tokens are only used once, issuers must maintain a list of all tokens that have been spent. This database grows indefinitely, making it more difficult and expensive to verify token validity. Riard proposes that these Chaumian tokens should expire at a block height announced in the gossip protocol per network. This means that senders will need to periodically repurchase these tokens or, if the implementation supports it, redeem them for new tokens signed with the new signing key after the previous one expires. This could result in senders paying a monthly economic cost or require them check in to ensure that old tokens are reissued. This can be automated for those who run their own Lightning nodes. For wallets built around a Lightning service provider (LSP), the LSP could handle the acquisition and maintenance and token provisioning on behalf of its users. This could be a problem for users who use light wallets. This proposal could be a great way to reduce channel jamming as an attack vector. It can also be combined with the basic up-front fees scheme. Most of the UX frictions can easily be handled by LSP users and those who own their own Lightning nodes. Even though the up-front fees can be a bit of a barrier, it is possible to prove ownership of a Bitcoin UTXO and use that instead of paying fees to acquire tokens. Shinobi contributed this guest post. These opinions are not necessarily those of BTC Inc.