A proposed successor to BOLT 11, BOLT 12 is a proposed upgrade to Lightning, Bitcoin’s most popular Layer 2 protocol.
This is an opinion piece by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
BOLT 12 is a proposal by Rusty Russel of Blockstream to optimize the way payments are made on Lightning and ultimately become the successor to BOLT 11. Even though there are many different features bundled together to make up the BOLT, this article will mainly focus on trade-offs and issues regarding one of them. First, I’ll quickly summarize some of the main features of the BOLT proposal:
BOLT: (base of Lightning technology; the Lightning equivalent of the Bitcoin improvement proposal [BIP] Features)
* Blind Paths: This is used for both payment bills and onion messages. It predefines and encrypts the last hops in a payment or onion message circuit so that the sender does not know where they are sending something, while still allowing it to arrive at the intended recipient.
* Schnorr Signatures: This allows all the different places where signatures are used in coordinating a Lightning payment or communicating with nodes to leverage Schnorr multisig in the future.
* Payer Proofs: Nodes now create a special key when requesting invoices, allowing them to prove, with a signature, that they have made a payment. This also guarantees in the event of reimbursement that only the real payer will be able to claim it.
* Invoice Merkle Trees: Invoices are now encoded as dedicated Merkle trees for each individual field. This way, if you ever need to prove that you made a payment or received an invoice, you can selectively choose which parts to reveal instead of having to show someone the entire invoice.
All of these things put together make a “Lightning Deal”. This allows you to post a single static QR code with information to ping a node on onion messages and receive a Lightning invoice for a specific payment on the Lightning Network itself. Currently, BOLT 11 invoices are only valid for the single payment for which they are generated, and although Keysend payments allow payments to be made without the invoice, they do not allow you to receive payment details in an invoice. signed by the receiving node and keep them for future recordings. BOLT 12 enables all the benefits of both: allowing a single static piece of data to facilitate payments to a receiving node while receiving invoices with details of each individual payment made. By the way, this also allows for quick and easy coordination of streaming payments, subscription payments, and more. that do not allow the recipient to charge money if the sender does not approve the transaction, while maintaining a simplified user experience.
Through the use of blind paths, it also dramatically improves one of the Lightning Network’s biggest privacy shortcomings: payment receivers doxxing a lot of private information to the sender during the process of receiving a payment. , such as the on-chain UTXOs associated with their channel as well as their place in the Lightning Network graph (i.e. which node they are connected to and receiving payment through). Blind paths are used both for receiving payments and for receiving the ping of the onion message to send a bill back to the sender.
BOLT 12 brings together many moving parts to facilitate this new way of coordinating payments on the Lightning Network. One of the biggest criticisms leveled at the proposal has been the inclusion of general purpose onion messages and concerns that it will open up new denial of service (DoS) attack vectors. . I think the logic here is completely incorrect, and I’ll explain why.
One of the biggest DoS (and privacy) issues with the Lightning protocol is probing. Each channel can have 483 HTLCs (Hash Time Lock Contracts) open at any given time, representing pending payments, due to transaction size limits in the Bitcoin protocol. This helps ensure that a channel close transaction can actually settle on the chain and not be rejected by the mempool because it is too large. Polling is the act of spamming payments through channels, channels that are intentionally designed to fail to gather information about how funds are balanced in a lightning channel. This consumes bandwidth, space that could be used to process real payments, and all around wastes network resources and information leaks that could be used to anonymize payments.
The problem with poll transactions is that they can be used to transmit arbitrary messages without paying a single sat for them. You can route a payment through the network that was designed never to succeed and include arbitrary data for the recipient, then just let the payment fail. This abuses the Lightning Network’s payment protocol to transport arbitrary information for free, and there’s no way to stop people from doing this at this time. You would have no way of knowing if a payment you are routing is genuine or if you are simply abusing your node to transmit data; when a payout fails, you can’t tell if it just failed organically or was designed to fail from the start. This is actually how Sphinxchat works, except obviously they send payments and don’t abuse the network for free.
Ultimately, this use of the Lightning Protocol saturates scarce throughput in the form of HTLC slots that could be used for “real” economic payments (real in quotes because obviously, who is to judge what economic activity is” real”) to transmit arbitrary data, and can currently be abused in a way where no one is actually paid to do so. This is a very real and already present DoS risk that exists on the Lightning Network.
There are a few proposed solutions to the probing problem and the DoS problem it creates, chief among which is the idea of paying a fee for a payment before it actually manages to go through. This is quite a controversial proposition, as it would mean that a sender will end up paying a fee for a payment whether or not it is successfully completed. The nature of any proposed solutions for this is beyond the scope of this article, but the fact is that there are proposed solutions, and none of them are currently implemented. Key point: they are not implemented.
So to me the argument that general onion messages “open a new DoS attack vector” for Lightning is completely misleading and a bogus argument. This attack vector already exists right now. In fact, it’s even worse than general onion messages because it wastes a scarce resource needed for payment routing – HTLC slots. General onion messages do not.
Onion messages are a feature that can be disabled, so your node can completely refuse to relay them, and also something that can be rate limited. What I mean by that is that your node could easily have a setting where it only transmits “x” messages per second, or “y” amount of data per second, or any other arbitrary timeline, and refuse to relay everything that exceeds these limits. This way your node can easily manage the amount of resources it allows to consume by passing general messages.
In other words, BOLT 12 does not open any new DoS attack vector; it simply takes an existing one that affects the network’s ability to process payments and moves it somewhere that doesn’t affect payment relay or consume any HTLC slots. It also has a way to mitigate resource consumption without further restricting payment flow. The worst thing that can happen is a massive spam event on the network – saturating the capacity of onion messages which would degrade the ability to use BOLT 12 offers or get a bill on the network.
This would not affect payment relay; it would not preclude BOLT 11’s ability to receive and pay bills; it would just mean that attempts to retrieve bills using BOLT 12 would fail as long as the network was spammed with onion messages. Also remember that individual nodes that didn’t want to deal with the slight increase in bandwidth usage could opt out and not relay onion messages. Everything as it currently works would continue to work, and an existing DoS attack vector would have some kind of relief valve where people who wanted to push arbitrary messages could do so in a way that didn’t waste slots HTLC or does not interfere with payment processing. , and anyone wishing to disable the new feature could do so.
In short, I think the “DoS vector” argument against BOLT 12 is nonsense. If people want to make arguments about the complexity of all the pieces of work, the development time needed to implement it, or other aspects of the proposal, I think those are all valid arguments to make. However, the argument against onion messages and new DoS vectors does not hold water.
This is a guest post from Shinobi. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
The views and opinions expressed herein are the views and opinions of the author and do not necessarily reflect those of Nasdaq, Inc.
