Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. In this issue we'll dive into a Core Lightning vulnerability disclosure, the new Lexe CLI, and Burak's latest L2 called Cube.
Core Lightning Vulnerability DisclosureCore Lightning Vulnerability Disclosure
Chandra Pratap disclosed a denial-of-service (DoS) vulnerability in Core Lightning, patched in v26.04. An attacker could trigger the hsmd daemon (responsible for managing the root secret) to abort during an ongoing channel opening (initiated by the attacker), causing the entire node to shut down. The attack doesn't require any specific condition and could be triggered by any node, as long as they're able to initiate a valid channel opening with the victim.
The root cause was discovered through fuzzing: passing a funding_txid that is all zeroes in the funding_created message led to a failed assertion in hsmd, causing the abort and the subsequent crash of the node.
On top of the vulnerability itself, two interesting aspects are that it was found during Pratap's Summer of Bitcoin internship, and was surfaced through fuzzing. This highlights the benefits of such programs and techniques, which have been increasingly developed in the Lightning (and larger Bitcoin) ecosystem in recent years, and continue to be.
Note: I somehow missed this disclosure when it was published on May 16th, hence why it only appears in this edition. Sorry about that!
Lexe CLILexe CLI
Lexe introduced the Lexe CLI, which lets users (and agents) interact with their Lexe node in a command line interface, from registering an anonymous account with Lexe, setting up and launching the node, to initiating payments.
For users that already have a wallet/node they interface with through the app, they can export the credentials from the mobile app and use them in the CLI. This way, they'll talk to their already existing node instead of launching (and funding!) a new one.
Cube Joining The GameCube Joining The Game
After inventing Ark, Burak is at it again with Cube, a "virtual machine designed to enable trusless (sic) smart contract execution natively on Bitcoin". It builds on Ark and BitVM to build what could be described as a channel factory in Ark where fund redemption can also be governed by any arbitrary condition.
To onboard into the Cube system, a participant funds a 2-of-2 output they share with the Engine, which is the coordinator in the Cube system. This output is then "lifted" into a corresponding 2-of-2 VTXO inside the Cube system. Similarly to Lightning's HTLCs, funds pledged to a user are manifested through a Zero-Knowledge Time-Locked Contract (ZKTLC), which is a "2-of-2 BitVM challenge-response relationship between the user and the Engine". If the Engine stops responding, the user can exit unilaterally by releasing a specific transaction that reveals the ZKTLC on-chain, where the BitVM challenge can be settled.
Of course, the above is a very high level summary of how Cube works, with the specific purpose to highlight where this new construct resembles Lightning. There are a lot of subtler details, which I don't fully grasp just yet. The executive summary is: arbitrary smart contract execution, optimistically off-chain, with a unilateral on-chain fallback. Sounds interesting!
European Commission Clarifies LN StatusEuropean Commission Clarifies LN Status
The European Commission, through the European Banking Authority, clarified its position on whether or not the TFR[1]/MiCAR[2] apply to Lightning transactions. In its response, it states clearly that if the initiating or beneficiary node of a payment is operated by a crypto-asset service provider (CASP) on behalf of their user, then the TFR applies. However, if the transaction is conducted in a peer-to-peer manner, without the involvement of a CASP, then the TFR doesn't apply.
"The use of the LN does not seem to require the intermediation of CASPs for allowing transactions. [...] CASPs offering their customers the possibility to transfer crypto-assets with the use of the LN fall within the scope of MiCAR and TFR and should therefore comply with the travel rule requirements (...). By contrast, the same use of the LN in mere peer to peer transactions not operated by CASPs, does not fall within the scope of MiCAR (recital 22 MiCAR), nor that of the TFR."
The entire ecosystem had pretty much operated through this assumption, but it's good to have it unambiguously clarified.
That's it for last week! Thank you so much for reading this far, and until next week!
Transfer of Funds Regulation, which includes the Travel Rule. ↩
https://twiiit.com/lexeapp/status/2060417702825734483