That 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 remodeled Lightning and in the end develop into the successor to BOLT 11. Although there are various totally different options packaged collectively with a view to compose the BOLT, this text is generally going to deal with the trade-offs and points relating to one in every of them. First, I’ll rapidly summarize among the key options of the BOLT proposal right here:
BOLT: (Foundation of Lightning Know-how; the Lightning equal of the Bitcoin Enchancment Proposal [BIP] specs)
* Blinded Paths: That is used each for fee invoices and onion messages. It predefines and encrypts the previous couple of hops in a fee or onion message circuit so the sender doesn’t know the place they’re sending one thing, whereas nonetheless permitting it to reach on the meant recipient.
* Schnorr signatures: this enables for all of the totally different locations signatures are utilized in coordinating a Lightning fee or in communication with nodes to benefit from Schnorr multisig sooner or later.
* Payer Proofs: nodes now create a particular key once they request invoices, permitting them to show, by a signature, that they’ve made a fee. This additionally ensures within the occasion of a refund that solely the actual payer can declare it.
* Bill Merkle Bushes: invoices at the moment are encoded as merkle timber dedicated to every particular person subject. This fashion, for those who ever have a must show that you simply made a fee or obtained an bill, you possibly can selectively select what items to disclose as a substitute of getting to indicate somebody your entire bill.
All of these items collectively assemble a “Lightning provide.” This lets you submit a single static QR code with info to ping a node over onion messages and obtain a Lightning bill for a selected fee over the Lightning Community itself. At present, BOLT 11 invoices are solely good for the only fee they’re generated for, and whereas keysend funds enable for making funds with out the bill, they don’t will let you obtain the main points of the fee in an bill signed by the receiving node and retain these for future information. BOLT 12 allows 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 fee made. As a fast sidenote this additionally allows fast and simple coordination of streaming funds, subscription funds, and so on. that don’t depart the receiver in a position to cost cash if the sender doesn’t approve the transaction, whereas sustaining a streamlined person expertise.
By the usage of blinded paths, it additionally massively improves one of many greatest privateness shortcomings of the Lightning Community: receivers of funds doxxing many non-public particulars to the sender within the strategy of receiving a fee, such because the on-chain UTXOs related to their channel in addition to their place within the Lightning Community graph (i.e., what node they’re related to and receiving the fee by). 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 plenty of transferring elements coming collectively to facilitate this new means of coordinating funds throughout the Lightning Community. One of many greatest criticisms introduced towards the proposal has been the inclusion of common objective onion messages and the fear that it could open new denial of service (DoS) assault vectors. I feel the logic right here is totally incorrect, and I’m going to stroll by why.
One of many greatest DoS points (and privateness points) with the Lightning protocol is probing. Every channel can have at any given time 483 HTLCs (hash time-lock contracts) open, representing pending funds, as a result of limits on the scale of a transaction within the Bitcoin protocol. That is to make sure that a channel closure transaction can truly choose chain, and never be rejected by the mempool for being too massive. Probing is the act of spamming funds by channels, channels which might be deliberately designed to fail with a view 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 info that could possibly be used to deanonymize funds.
The factor with probing transactions is, they can be utilized to move arbitrary messages with out paying a single sat for them. You’ll be able to route a fee by the community that was designed by no means to succeed and embrace arbitrary knowledge for the receiver, after which merely let the fee fail. This abuses the fee protocol within the Lightning Community to move arbitrary info without spending a dime, and there’s no option to cease folks from doing this proper now. You’d don’t have any means of understanding whether or not a fee you might be routing is real or just abusing your node to move knowledge; when a fee fails you possibly can’t know whether or not it simply failed organically or was designed to fail from the beginning. That is truly how Sphinxchat works, with the exception that, clearly, they ship funds and don’t abuse the community without spending a dime.
Finally, this use of the Lightning protocol saturates scarce throughput within the type of HTLC slots that could possibly be used for “actual” financial funds (actual in quotations as a result of clearly, who’s to guage what’s “actual” financial exercise) to move arbitrary knowledge, and may at present be abused in a means the place nobody is definitely paid for doing so. This can be a very actual and already current DoS threat that exists on the Lightning Community.
There are a number of proposed options to the probing drawback and the DoS difficulty it creates, chief of which is the thought of paying charges for a fee earlier than it truly succeeds in going by. This can be a fairly contentious proposal, as it could imply {that a} sender will wind up paying charges for a fee no matter whether or not it’s efficiently accomplished. The character of all the proposed options for that 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 aren’t carried out.
So, to me, the argument that common onion messages “opens a brand new DoS assault vector” for Lightning is totally fallacious and a false argument. That assault vector already exists proper now. Actually, it’s even worse than common onion messages, as a result of it wastes a scarce useful resource obligatory for routing funds — HTLC slots. Basic onion messages don’t.
Onion messages are a characteristic that may be turned off, so your node can fully choose out of relaying them, and in addition one thing that may be rate-limited. What I imply by that’s your node might simply have a setting the place it solely passes “x” messages per second, or “y” quantity of knowledge per second, or every other arbitrary timeline, and refuse to relay something that exceeds these limits. On this means your node can simply handle the quantity of sources it permits to be consumed passing common messages.
In different phrases, BOLT 12 doesn’t open any new DoS assault vector; it merely takes an present one which impacts the power of the community to course of funds and strikes it someplace that doesn’t have an effect on fee relaying or devour any HTLC slots. It additionally has a option to mitigate useful resource consumption with out additional limiting fee movement. The worst factor that would occur is a large spam occasion on the community — saturating onion message capability that may degrade the power to make use of BOLT 12 presents or getting an bill over the community.
This wouldn’t have an effect on fee relaying; this is able to not stop the power to obtain and pay BOLT 11 invoices; it could merely imply makes an attempt to fetch invoices utilizing BOLT 12 would fail as long as the community was being spammed with onion messages. Additionally keep in mind particular person nodes who didn’t wish to take care of the slight enhance in bandwidth utilization might choose out and never relay onion messages. Every little thing because it capabilities proper now would proceed to work, and an present DoS assault vector would have a form of aid valve the place individuals who wished to move arbitrary messages might 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 characteristic might achieve this.
Briefly, I feel the “DoS vector” argument towards BOLT 12 is nonsense. If folks wish to provide arguments in regards to the complexity of all of the working items, the event time essential to implement it or different features of the proposal, I feel these are all legitimate arguments to make. Nonetheless, the argument towards onion messages and new DoS vectors doesn’t maintain water.
This can be a visitor submit by Shinobi. Opinions expressed are solely their very own and don’t essentially mirror these of BTC Inc or Bitcoin Journal.
