This is an opinion editorial from Shinobi, a self-taught teacher in the bitcoin space and tech-oriented bitcoin podcast host.
BOLT 12 is a proposal from Blockstream’s Rusty Russell on how payments are made on Lightning and eventually become the successor to BOLT 11. Even though there are many different features packed together to compose BOLT, this article is going to focus mostly on the trade-offs and issues regarding one of them. First, let me summarize here some of the key features of the Bolt offer:
Bolt: (Lightning Technology Base; Lightning Equivalent to Bitcoin Improvement Proposal) [BIP] Specifications)
* Blind Paths: This is used for both payment invoices and onion messages. It predefined and encrypts the last few hops in the payment or onion messaging circuit so that the sender does not know where they are sending something, while still allowing it to reach the intended recipient.
* Schnorr Signatures: This allows signatures to be used in all different places in coordination with Lightning payments or in communication with nodes to take advantage of Schnorr Multisig in the future.
* Payer Proof: Nodes now generate a special key when they request an invoice, allowing them to prove they have paid through signature. It also guarantees a refund in the event that only the original payee can claim it.
* Invoice Merkle Tree: Invoices are now encoded as a Merkle tree committed to each individual region. That way, if you ever need to prove that you paid or received an invoice, you can selectively choose which pieces to reveal, rather than showing someone the entire invoice.
All of these things together make up a “power offer”. This allows you to ping a node on Onion Messages, post a static QR code with the information, and receive a Lightning invoice for a specific payment on the Lightning Network itself. Currently, BOLT 11 invoices are only good for the payment for which they are generated, and while keyend allows payment without invoicing, they allow you to get the payment details in an invoice signed by the recipient node. Do not allow and retain them for future records. BOLT 12 enables all the benefits of both: allowing the receiving node to facilitate payments to a single piece of static data, while still receiving an invoice with the details of each individual payment. As a quick idea it also enables quick and easy syncing of streaming payments, subscription payments, etc., while maintaining a streamlined user experience, enabling the sender to charge money to the receiver if the transaction is not approved. does not leave.
Through the use of blind paths, it vastly improves on one of the Lightning Network’s biggest privacy shortcomings: payment recipients in the process of receiving payments give the sender a number of private details, such as those associated with them. On-chain UTXOs channels as well as their location in the Lightning Network graph (ie, which node they are connected to and receiving payments through). Blind paths are used both in receiving the Onion message ping for receiving the payment as well as sending the invoice back to the sender.
The BOLT 12 Lightning Network has a lot of moving parts coming together to facilitate this new way of coordinating payments. One of the biggest criticisms brought against the proposal is its inclusion of general-purpose Onion messages and concerns that it would open up denial of service (DoS) attack vectors. I think the logic here is completely wrong, and why am I running.
One of the biggest DoS issues (and privacy issues) with the Lightning Protocol is under investigation. Due to the transaction size limit in the bitcoin protocol, each channel can have 483 HTLCs (Hash Time-Locked Contracts) open at any time, representing pending payments. 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 deliberately designed to fail to collect information about how funds are balanced in a Lightning channel. It eats up bandwidth, space that could be used to process actual payments, and leaks information as well as wasting resources on the network that can be used to anonymize payments. Is.
The thing to check for transactions is that they can be used to send arbitrary messages without paying a single payment for them. You can route a payment through a network that was designed to never succeed and contain arbitrary data for the receiver, and then let the payment fail. It arbitrarily abuses the payment protocol in the Lightning Network to deliver information for free, and there’s no way to stop people from doing so right now. You will have no way of knowing whether the payment you are routing is genuine or just abusing your node to pass data; When a payment fails you can’t know whether it failed systematically or was designed to fail from the beginning. This is exactly how Sphinxchat works, with the exception that, apparently, they send payments and do not abuse the network for free.
Ultimately, this use of the Lightning protocol saturates the scarce throughput in the form of HTLC slots that can be used for “real” economic payments (real in the quote because obviously, that is, to judge “real” economic activity). ) for passing 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 existing DoS risk that exists on the Lightning Network.
There are a few proposed solutions to the probation problem and the DoS issue that it creates, chief of which is the idea of paying a fee for payment, before it is actually successful. This is a very controversial proposition, as it would mean that a sender would stop paying a fee for the payment whether it was successfully completed or not. The nature of all proposed solutions to this is beyond 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 the general Onion message to Lightning “opens up a new DoS attack vector” is a completely false and erroneous argument. That attack vector already exists. In fact, it’s worse than normal Onion messages, as it wastes a scarce resource needed for routing payments – HTLC slots. Not a normal onion message.
Onion messaging is a feature that can be turned off, so your node can opt out of relaying them entirely, and also something that may be rate-limiting. What I mean is that your node could easily have a setting where it only passes “x” messages per second, or “y” data per second, or any other arbitrary timeline, and any more than these limits Refuses to relay the thing. This way your node can more easily manage the amount of resources to be consumed for passing normal messages.
In other words, BOLT 12 does not open any new DoS attack vectors; It simply takes an existing one that affects the ability of the network to process payments and moves it somewhere that doesn’t affect payment relaying or consumes any HTLC slots. It also has a way of reducing resource consumption without further restricting payment flow. The worst thing that can happen is a huge spam incident on the network – saturated onion messaging capacity that will reduce the ability to use BOLT 12 offers or receive invoices on the network.
This payment will not affect relaying; It will not prevent the ability to receive and pay BOLT 11 invoices; This would simply mean that as long as the network was being spammed with Onion messages, attempts to fetch invoices using BOLT 12 would fail. Also remember that individual nodes that did not want to deal with a slight increase in bandwidth usage could opt out and not relay Onion messages. Whatever works now will continue to work, and the current DoS attack vector will have a relief valve of sorts, where people who want to deliver arbitrary messages can do so in a way that doesn’t waste HTLC slots or Do not interrupt the payment process. , and anyone who wants to opt out of the new feature can do so.
In short, I think the “DoS vector” argument against BOLT 12 is nonsense. If people want to argue about the complexity of all the work pieces, the development time required to implement it, or other aspects of the proposal, I think these are all valid arguments. However, the argument against onion messages and the new DoS vectors has no merit.
This is a guest post by Shinobi. The opinions expressed are solely their own and do not necessarily reflect the views of BTC Inc. bitcoin magazine,
