This is an opinion editorial by Shinobi, a self-taught educator within the Bitcoin area and tech-oriented Bitcoin podcast host.
BOLT 12 is a proposal from Rusty Russel of Blockstream to optimize how funds are revamped Lightning and in the end grow to be the successor to BOLT 11. Even although there are many various options packaged collectively so as to compose the BOLT, this text is principally going to deal with the trade-offs and points relating to one among them. First, I’ll shortly summarize a few of the key options of the BOLT proposal right here:
BOLT: (Basis of Lightning Technology; the Lightning equal of the Bitcoin Improvement Proposal [BIP] specs)
* Blinded Paths: This is used each for cost invoices and onion messages. It predefines and encrypts the previous couple of hops in a cost or onion message circuit so the sender doesn’t know the place they are sending one thing, whereas nonetheless permitting it to arrive on the supposed recipient.
* Schnorr signatures: this enables for all of the completely different locations signatures are utilized in coordinating a Lightning cost or in communication with nodes to make the most of Schnorr multisig sooner or later.
* Payer Proofs: nodes now create a particular key when they request invoices, permitting them to show, by way of a signature, that they have made a cost. This additionally ensures within the occasion of a refund that solely the actual payer can declare it.
* Invoice Merkle Trees: invoices are now encoded as merkle timber dedicated to every particular person subject. This means, when you ever have a necessity to show that you just made a cost or obtained an bill, you may selectively select what items to reveal as a substitute of getting to present somebody your entire bill.
All of this stuff collectively assemble a “Lightning offer.” This permits you to publish a single static QR code with data to ping a node over onion messages and obtain a Lightning bill for a selected cost over the Lightning Network itself. Currently, BOLT 11 invoices are solely good for the only cost they are generated for, and whereas keysend funds enable for making funds with out the bill, they don’t enable you to obtain the main points of the cost in an bill signed by the receiving node and retain these for future data. BOLT 12 permits all the advantages of each: permitting a single piece of static knowledge to facilitate funds to a receiving node whereas nonetheless receiving invoices with the main points of every particular person cost made. As a fast sidenote this additionally permits fast and simple coordination of streaming funds, subscription funds, and many others. that don’t go away the receiver in a position to cost cash if the sender doesn’t approve the transaction, whereas sustaining a streamlined consumer expertise.
Through the usage of blinded paths, it additionally massively improves one of many largest privateness shortcomings of the Lightning Network: receivers of funds doxxing many personal particulars to the sender within the strategy of receiving a cost, such because the on-chain UTXOs related to their channel in addition to their place within the Lightning Network graph (i.e., what node they are related to and receiving the cost by way of). Blinded paths are utilized in each receiving funds, in addition to receiving the onion message ping to ship an bill again to the sender.
BOLT 12 is lots of shifting components coming collectively to facilitate this new means of coordinating funds throughout the Lightning Network. One of the largest criticisms introduced in opposition to the proposal has been the inclusion of basic objective onion messages and the fear that it will open new denial of service (DoS) assault vectors. I believe the logic right here is utterly incorrect, and I’m going to stroll by way of why.
One of the largest DoS points (and privateness points) with the Lightning protocol is probing. Each channel can have at any given time 483 HTLCs (hash time-lock contracts) open, representing pending funds, due to the boundaries on the dimensions of a transaction within the Bitcoin protocol. This is to make sure that a channel closure transaction can really choose chain, and never be rejected by the mempool for being too giant. Probing is the act of spamming funds by way of channels, channels that are deliberately designed to fail so as to collect details about how funds are balanced in a Lightning channel. This eats up bandwidth, area that could possibly be used to course of real funds, and throughout wastes sources on the community in addition to leaks data that could possibly be used to deanonymize funds.
(*12*)The factor with probing transactions is, they can be utilized to cross arbitrary messages with out paying a single sat for them. You can route a cost by way of the community that was designed by no means to succeed and embrace arbitrary knowledge for the receiver, after which merely let the cost fail. This abuses the cost protocol within the Lightning Network to transport arbitrary data without cost, and there is no means to cease individuals from doing this proper now. You would haven’t any means of figuring out whether or not a cost you are routing is real or just abusing your node to cross knowledge; when a cost fails you may’t know whether or not it simply failed organically or was designed to fail from the beginning. This is really how Sphinxchat works, with the exception that, clearly, they ship funds and don’t abuse the community without cost.
Ultimately, this use of the Lightning protocol saturates scarce throughput within the type of HTLC slots that could possibly be used for “real” financial funds (actual in quotations as a result of clearly, who is to choose what is “real” financial exercise) to cross arbitrary knowledge, and may at present be abused in a means the place nobody is really paid for doing so. This is a really actual and already current DoS threat that exists on the Lightning Network.
There are just a few proposed options to the probing downside and the DoS situation it creates, chief of which is the concept of paying charges for a cost earlier than it really succeeds in going by way of. This is a fairly contentious proposal, as it will imply {that a} sender will wind up paying charges for a cost no matter whether or not it is efficiently accomplished. The nature of all the proposed options for this is exterior the scope of this text, however the level is that there are proposed options, and none of them are at present carried out. Key level: they are not carried out.
So, to me, the argument that basic onion messages “opens a new DoS attack vector” for Lightning is utterly fallacious and a false argument. That assault vector already exists proper now. In truth, it is even worse than basic onion messages, as a result of it wastes a scarce useful resource crucial for routing funds — HTLC slots. General onion messages don’t.
Onion messages are a function that may be turned off, so your node can utterly choose out of relaying them, and in addition one thing that may be rate-limited. What I imply by that is your node may simply have a setting the place it solely passes “x” messages per second, or “y” quantity of knowledge per second, or some other arbitrary timeline, and refuse to relay something that exceeds these limits. In this fashion your node can simply handle the quantity of sources it permits to be consumed passing basic messages.
In different phrases, BOLT 12 doesn’t open any new DoS assault vector; it merely takes an current one which impacts the power of the community to course of funds and strikes it someplace that doesn’t have an effect on cost relaying or devour any HTLC slots. It additionally has a means to mitigate useful resource consumption with out additional proscribing cost stream. The worst factor that might occur is a large spam occasion on the community — saturating onion message capability that might degrade the power to use BOLT 12 gives or getting an bill over the community.
This wouldn’t have an effect on cost relaying; this might not stop the power to obtain and pay BOLT 11 invoices; it will merely imply makes an attempt to fetch invoices utilizing BOLT 12 would fail as long as the community was being spammed with onion messages. Also bear in mind particular person nodes who didn’t need to cope with the slight enhance in bandwidth utilization may choose out and never relay onion messages. Everything because it features proper now would proceed to work, and an current DoS assault vector would have a type of reduction valve the place individuals who wished to cross arbitrary messages may achieve this in a means that doesn’t waste HTLC slots or impede the processing of funds, and anybody who wished to choose out of the brand new function may achieve this.
In brief, I believe the “DoS vector” argument in opposition to BOLT 12 is nonsense. If individuals need to provide arguments concerning the complexity of all of the working items, the event time crucial to implement it or different points of the proposal, I believe these are all legitimate arguments to make. However, the argument in opposition to onion messages and new DoS vectors doesn’t maintain water.
This is a visitor publish by Shinobi. Opinions expressed are totally their personal and don’t essentially replicate these of BTC Inc or Bitcoin Magazine.
