[ad_1]
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
BOLT 12 is a proposal from Rusty Russel of Blockstream to optimize how payments are made over Lightning and ultimately become the successor to BOLT 11. Even though there are many different features packaged together in order to compose the BOLT, this article is mostly going to focus on the trade-offs and issues regarding one of them. First, I will quickly summarize some of the key features of the BOLT proposal here:
BOLT: (Basis of Lightning Technology; the Lightning equivalent of the Bitcoin Improvement Proposal [BIP] specifications)
* Blinded Paths: This is used both for payment invoices and onion messages. It predefines and encrypts the last few hops in a payment or onion message circuit so the sender does not know where they are sending something, while still allowing it to arrive at the intended recipient.
* Schnorr signatures: this allows for all the different places signatures are used in coordinating a Lightning payment or in communication with nodes to take advantage of Schnorr multisig in the future.
* Payer Proofs: nodes now create a special key when they request invoices, allowing them to prove, through a signature, that they have made a payment. This also guarantees in the event of a refund that only the real payer can claim it.
* Invoice Merkle Trees: invoices are now encoded as merkle trees committed to each individual field. This way, if you ever have a need to prove that you made a payment or received an invoice, you can selectively choose what pieces to reveal instead of having to show someone the entire invoice.
All of these things together construct a “Lightning offer.” This allows you to post a single static QR code with information to ping a node over onion messages and receive a Lightning invoice for a specific payment over the Lightning Network itself. Currently, BOLT 11 invoices are only good for the single payment they are generated for, and while keysend payments allow for making payments without the invoice, they do not allow you to receive the details of the payment in an invoice signed by the receiving node and retain those for future records. BOLT 12 enables all the benefits of both: allowing a single piece of static data to facilitate payments to a receiving node while still receiving invoices with the details of each individual payment made. As a quick sidenote this also enables quick and easy coordination of streaming payments, subscription payments, etc. that do not leave the receiver able to charge money if the sender does not approve the transaction, while maintaining a streamlined user experience.
Through the use of blinded paths, it also massively improves one of the biggest privacy shortcomings of the Lightning Network: receivers of payments doxxing many private details to the sender in 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., what node they are connected to and receiving the payment through). Blinded paths are used in both receiving payments, as well as receiving the onion message ping to send an invoice back to the sender.
BOLT 12 is a lot of moving parts coming together to facilitate this new way of coordinating payments across the Lightning Network. One of the biggest criticisms brought against the proposal has been the inclusion of general purpose onion messages and the worry that it would open new denial of service (DoS) attack vectors. I think the logic here is completely incorrect, and I’m going to walk through why.
One of the biggest DoS issues (and privacy issues) with the Lightning protocol is probing. Each channel can have at any given time 483 HTLCs (hash time-lock contracts) open, representing pending payments, due to the limits on the size of a transaction in the Bitcoin protocol. This is to ensure that a channel closure transaction can actually settle on chain, and not be rejected by the mempool for being too large. Probing is the act of spamming payments through channels, channels that are intentionally designed to fail in order to gather information about how funds are balanced in a Lightning channel. This eats up bandwidth, space that could be used to process genuine payments, and all around wastes resources on the network as well as leaks information that could be used to deanonymize payments.
The thing with probing transactions is, they can be used to pass 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 receiver, and then simply let the payment fail. This abuses the payment protocol in the Lightning Network to transport arbitrary information for free, and there is no way to stop people from doing this right now. You would have no way of knowing whether a payment you are routing is genuine or simply abusing your node to pass data; when a payment fails you can’t know whether it just failed organically or was designed to fail from the start. This is actually how Sphinxchat works, with the exception that, 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 quotations because obviously, who is to judge what is “real” economic activity) to pass arbitrary data, and can currently be abused in a way where no one is actually paid for doing 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 issue it creates, chief of which is the idea of paying fees for a payment before it actually succeeds in going through. This is a pretty contentious proposal, as it would mean that a sender will wind up paying fees for a payment regardless of whether it is successfully completed. The nature of all of the proposed solutions for this is outside the scope of this article, but the point 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 “opens a new DoS attack vector” for Lightning is completely fallacious and a false argument. That attack vector already exists right now. In fact, it is even worse than general onion messages, because it wastes a scarce resource necessary for routing payments — HTLC slots. General onion messages do not.
Onion messages are a feature that can be turned off, so your node can completely opt out of relaying them, and also something that can be rate-limited. What I mean by that is your node could easily have a setting where it only passes “x” messages per second, or “y” amount of data per second, or any other arbitrary timeline, and refuse to relay anything that exceeds these limits. In this way your node can easily manage the amount of resources it allows to be consumed 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 ability of the network to process payments and moves it somewhere that does not affect payment relaying or consume any HTLC slots. It also has a way to mitigate resource consumption without further restricting payment flow. The worst thing that could happen is a massive spam event on the network — saturating onion message capacity that would degrade the ability to use BOLT 12 offers or getting an invoice over the network.
This wouldn’t affect payment relaying; this would not prevent the ability to receive and pay BOLT 11 invoices; it would simply mean attempts to fetch invoices using BOLT 12 would fail so long as the network was being spammed with onion messages. Also remember individual nodes who did not want to deal with the slight increase in bandwidth usage could opt out and not relay onion messages. Everything as it functions right now would continue to work, and an existing DoS attack vector would have a sort of relief valve where people who wanted to pass arbitrary messages could do so in a way that does not waste HTLC slots or impede the processing of payments, and anyone who wanted to opt out of the new feature could do so.
In short, I think the “DoS vector” argument against BOLT 12 is nonsense. If people want to offer arguments about the complexity of all the working pieces, the development time necessary to implement it or other aspects of the proposal, I think these 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 by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
[ad_2]
Source link
Comments are closed.