We’re notifying our audience on Medium that we have migrated to the official Blockstream blog (blog.blockstream.com), where the entire backlog of articles is now available, and the team will post all future engineering efforts and announcements.

For the latest news, please subscribe to the official Blockstream blog as we continue to focus on cutting-edge Bitcoin research and to build out layer-2 infrastructure.

If you have any questions, feel free to reach out via the Build On L2 community (buildonl2.com) or one of our Telegram groups below. Thank you!

Green
Jade
Finance
Core Lightning
Liquid

Medium Blog Now Retired, Follow Us on the Official Blockstream Blog was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Andrew Poelstra

Introduction

This is the third and final post in our series about the improvements we’ve deployed on Liquid as part of our Taproot launch. Our previous two posts talked about Taproot itself and Partially Signed Elements Transactions. In this post, we’ll describe the new opcodes that we’ve introduced to Elements Script, what they can be used for, and what we’re doing with them.

This set of opcodes is a major set of improvements to Script since the launch of Elements Alpha in 2015. Our research team has also been innovating on Bitcoin-related applied cryptography, with significant work on MuSig, the Elements blockchain, and the Lightning Network, and continued work on scripting and Simplicity. In particular, we contributed heavily to Taproot on Bitcoin, and some of the changes to Elements Script have been inherited from that, including:

• The removal of fixed numeric limits on opcode counts and script sizes;
• The replacement of ECDSA signatures with Schnorr;
• The replacement of CHECKMULTISIG with CHECKSIGADD, allowing batch-verification of multiple signatures
• Numerous OP_SUCCESS opcodes, which expand the set of opcodes that we could soft-fork into the network relative to the old NOP opcodes.

We’ll also talk about covenants, which give Script the ability to constrain payment flows to construct “smart contracts’’ that attach conditions to coins or other assets. Covenants have been proposed for Bitcoin in many forms over the years but have been present in Elements from the very beginning. With Tapscript, we’ve taken developer feedback from our original covenant implementation and introduced new opcodes that will make covenants more expressive, efficient, and ergonomic.

Finally, we’ll briefly talk about Elements Miniscript, our extension of Bitcoin’s Miniscript language, which makes use of these opcodes to produce covenant-enabled scripts. This is under rapid development, and we’re excited to see it opening new applications on Liquid. We’ll cover this subject more in a future post.

Covenants and Assets

Covenants were initially proposed for Bitcoin by Greg Maxwell in 2013 in a somewhat-joking manner, asking users to think up amusingly bad applications for them. While these bad ideas are fun to think about, they unfortunately seem to have overshadowed the idea of covenants to this day, even if the concerns are not particularly practical or even specific to covenants. Partly relating to this line of risk reasoning, covenants have remained a hotly-debated topic in the Bitcoin space.

The most recent and popular proposal for covenants in Bitcoin is OP_CTV, which has deliberately reduced functionality in order to avoid potential controversy.

In our view, these fears are largely overblown. They stem from the idea that covenants could be used to implement a “taint” on existing Bitcoins, such as requiring a 3rd-party signature for their use, which would spread throughout the coin supply and be impossible to remove. But such a scheme can actually be implemented today, by use of 2-of-2 CHECKMULTISIG scripts in which one party refuses to sign transactions that don’t preserve the 2-of-2 “covenant” restriction. Nobody has done this, and with good reason: these coins would obviously not be accepted by users in place of ordinary coins and could not be accepted by users with a fiduciary or other legal duty to custody ordinary coins. Furthermore, the resulting coins would require higher network fees to spend due to their extra weight and increase the complexity of wallets that could spend them.

Trying the same thing with covenants would be even more expensive and require even greater wallet complexity, which nobody would be interested in implementing and users would reject.

Further evidence that covenants are harmless is that they have existed on the Liquid Network since its launch in 2018, and there have been no viral covenants spreading throughout the system. (Although, as we’ll see, there are technical reasons for low uptake of covenants on Liquid in general.)

Covenants would introduce new capabilities to Bitcoin, such as vaults or velocity limits, giving users more flexibility in the ways that they custody their coins.

In Elements, where we have issued asset support, the functionality provided by covenants is much greater; we can:

• Construct open-ended limit orders or other algorithmic trades.
• Construct financial derivatives such as options.
• Create “control tokens” which are NFTs that enable functionality in other contracts.

In a multi-asset scenario with a rich set of arithmetic opcodes, we would be able to match the feature set of Ethereum and competitors, and by avoiding Turing completeness, we should be able to implement strong forms of analysis. But as we will see, the story is more complex than this.

Elements and Bitcoin Script

Elements was written in 2015 as a fork of Bitcoin with extra features and was launched as a test network called Elements Alpha that year. This network predated Segwit, let alone Taproot; it predated issued assets; it had a two-stage peg scheme which ultimately proved unnecessarily complex and bug-prone and was redesigned before deployment on Liquid. Its major features were Confidential Transactions, which were later extended to support issued assets, a nascent scheme for segregating witnesses that was simplified and ported to Bitcoin as Segwit, and a set of extra opcodes for enabling covenants. It is the latter that we’ll focus on in this post.

When we introduced the original Elements and Liquid set of opcodes, Bitcoin Script relied on manual, low-level programming and was also difficult to formally analyze. Our extensions increased the expressivity of the language but didn’t address these underlying limitations. Users were able to develop some advanced applications, such as Lending on Liquid, but this development was more a testament to determined human ingenuity than the ease of programming on our scripting platform. Other applications, such as Bitmatrix, could only be deployed after the upgrades to the script system described in this post. Since then, independently of Elements, Blockstream Research developed Miniscript, a new way to model Bitcoin Script that would solve these problems of analysis.

In particular, with Miniscript, it is possible to automatically enumerate all the keys in a script and determine which sets are needed to produce a transaction; find an upper bound on the size of such a transaction prior to gathering signatures; answer semantic questions about which conditions must be met in order to spend coins; and compute the exact encodings for scripts and witnesses. Miniscript complements Partially Signed Bitcoin Transactions, also developed by Blockstream Research’s Andrew Chow, with Pieter Wuille being part of the original concept and development, which provides a protocol for assembling the data needed to produce a transaction. This allows wallets to sign transactions even if they don’t understand (or pre-date) the exact script being satisfied; they just need to check that the transaction makes sense, produce an ECDSA or Schnorr signature, and let the Miniscript tooling do the rest.

However, even with Miniscript under our belt, we found no straightforward path to “easy covenants” on Elements. Our 2016-era covenant constructions were difficult to use in a generic way, and their large size in practice is hard to avoid being limited by the 201-opcode limit we’d inherited from Bitcoin. So even as Bitcoin Script became more powerful through Miniscript, PSBT and Tapscript (designed with Miniscript in mind), Elements’ extensions to Script were unable to come along for the ride.

Breaking Through: New Abstractions

In February of 2021, Blockstream Researchers Andrew Poelstra and Sanket Kanjalkar finally found a way to combine Elements’ covenants with Miniscript. Essentially, we would construct covenant-enabled scripts inside “the machine,” a fixed-size Script template which would use the CHECKSIGFROMSTACK (CSFS) opcode to extract all of the transactions’ data and leave it on the stack in fixed locations where the “real code’’ could efficiently access it. This lets us amortize the high cost of CSFS-style covenants across many conditions on the spending transaction.

In fact, we later moved away from this initial approach, but the step propelled us past the concept limitation of how to practically construct generic covenants, and let us see what the real limitations of Elements Script were:

• 31-bit big-endian arithmetic inherited from Bitcoin, which could not be easily used with the 64-bit little-endian amounts used by transactions.
• Compounding this, no multiplication or division opcodes; Elements had added bitshifts and other arithmetic operations but not the basics needed to do, for example, fee calculations.
• For fee calculations, CSFS-style covenants can’t access the transaction weight and therefore can’t compute its feerate.
• An inability to hash more than 520 bytes of data is caused by the combination of Bitcoin’s 520-byte stack element size limit and its inflexible SHA256 opcode. Combined with CSFS’s need to hash significant amounts of transaction data at once, this created limits on total transaction sizes, making wallet authors’ lives much more difficult.
• An inability to execute scripts with more than 201 opcodes, with dozens required by the CSFS machine and dozens more needed to convert 64-bit integers into 32-bit ones and back.
• An inability to do elliptic curve arithmetic except for signature validation, which can be coerced into doing many things but not into verifying that Taproot outputs are correctly formed. Had we retained this limitation in Tapscript, it would have reduced functionality while increasing the complexity of our scripts.

Once we recognized these problems, they became straightforward to address:

• We added new opcodes for manipulating 64-bit values, including multiplication, as well as opcodes for converting them into the old-style 32-bit values for use with the ordinary Bitcoin opcodes.
• We added, “direct introspection” opcodes to access transaction data, eliminating the need for “the machine” and reducing our opcode counts. We also added a TXWEIGHT opcode to access the weight of the transaction for fee rate calculations.
• We added “streaming hash” opcodes to allow feeding data into a hash engine without needing to put it all into a single stack element. This cleanly avoids the 520-byte stack element limit without requiring any more resource usage from the script interpreter.
• We added an ECMULSCALARVERIFY opcode to handle Taproot outputs, pay-to-contract commitments, and other elliptic curve cryptography operations.
• We followed Bitcoin’s lead in eliminating the 201-opcode limit, although with the above improvements, it may have been manageable.

Once complete, we had a small set of new opcodes that easily fit into the Bitcoin Script model (i.e., no introduced disk accesses, unbounded resource use, or complex control flow such as looping) that solved big problems allowing for production-grade covenants on Elements.

Here is a complete list of the new opcodes.

Having surmounted this barrier, we are ready to tackle some deeper issues with covenants, which are not unique to Elements.

As a concrete example of new things we can do with these opcodes, consider the vaulting scheme where we restrict that only MAX_WITHDRAW can be withdrawn at a time within 60 blocks time.

To create this covenant, we need to respect the following conditions (described in Miniscript notation, which we will cover in detail in a future post).

• Partial Withdrawal(partial_withdraw): If there are more than MAX_WITHDRAW sats in the covenant, then the covenant should have at least total_value — MAX_WITHDRAW remaining.
• “num64_gt(curr_inp_v,MAX_WITHDRAW)”: Total input sats more than MAX_SATS
• “asset_eq(curr_inp_asset,out_asset(0))”: Input assets and output asset 0 are same
• “num64_geq(out_v(0),sub64(curr_inp_v,MAX_WITHDRAW))”: The value of output should be atleast total_value — MAX_WITHDRAW
• “spk_eq(curr_inp_spk,out_spk(0))”: The remaining coins are sent to the covenant
• Full Withdrawal(full_withdraw): If the covenant has less than MAX_WITHDRAW sats, then outputs have no constraint
• num64_leq(curr_inp_v,MAX_WITHDRAW)
• Key Control(keys): Wait 60 blocks before spending again and require a key K to spend it.
• pk(K): Requires signature from key K
• older(60): 60 blocks waittime before the next withdrawal
• curr_idx_eq(0): The current spending index must be 0. This prevents the so-called half spend problem where we can spend two covenant utxos together, and one of them can escape the covenant
• Finally, we combine all the above conditions: and(keys,or(full_withdraw,partial_withdraw))

It’s possible to extend these with emergency withdrawal keys, multi-step withdrawals, whitelisting, and multi-sig custodies.

Open Problems and Future Work

By extending Miniscript with covenant support and providing opcodes to do this efficiently, we created a framework in which users can easily construct covenant scripts, understand these scripts’ behavior, and create complete transactions that execute these covenant contracts. But in doing so, we undermine the recursive structure of Miniscript and therefore break some forms of analysis.

For example, it’s possible to “compose” two Miniscripts by creating an and_b node whose two children are the two original scripts. (In terms of Script, we are just concatenating the original scripts and adding a BOOLAND opcode at the end.) If a user is convinced that she can satisfy each of the original scripts independently, she can be assured that she can satisfy the combined script.

Conversely, if she wants to determine the satisfiability of a complex script, she can recursively step through the script: whenever she sees an and node she must satisfy both sub-scripts while whenever she sees an or node she must satisfy one of them.

With covenants, this form of composition is no longer valid. While you can still combine two scripts using and_b to get a syntactically valid script, the result might be unsatisfiable even if both sub-scripts can be satisfied. For example, consider combining a script that requires the first output of the transaction to burn asset A with a script that requires the first output of the transaction to burn asset B. Clearly, both cannot be satisfied simultaneously.

In general, because covenants introduce global conditions on the transaction under construction, individual script fragments can have non-local effects on other script fragments. Alternatively, we can observe that in Bitcoin Miniscript we can think of our scripts as monotone functions of spending conditions. A script represents a rule for deciding which sets of spending conditions (signatures, hash preimages, etc.) are valid to spend a coin, and which sets are invalid. These rules being monotone means that if some set of conditions is valid, then any superset is.

With covenants in the picture, this model in terms of monotone functions simply does not apply, and so we lose the general and powerful analysis tools that Miniscript provides. Instead, covenant-enabled Elements Miniscript programs need to be analyzed in an ad-hoc fashion, in which specific questions are asked and answered.

Simplicity, a wholesale replacement for Script that we are working on in parallel, also has this limitation. To make this sort of ad-hoc analysis tenable, Simplicity’s interpreter has a reference implementation in the Coq theorem proving assistant, meaning that while humans need to come up with the right questions to ask, the answers at least will be rock solid and machine-checkable. With Elements Miniscript, programs are entirely dependent on human code review. We hope that we have designed it so that powerful programs can nonetheless be simple and obviously correct.

Going forward, we plan to keep expanding the functionality of Elements Miniscript, write supporting tooling and wallet libraries that can use it to produce and interact with covenants, and continue pushing forward on Simplicity, which will be even more expressive than the newly-expanded Elements Script.

Happy hacking!

Note: This article was originally posted on https://blog.blockstream.com/tapscript-new-opcodes-reduced-limits-and-covenants/

Tapscript: New Opcodes, Reduced Limits and Covenants was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are excited to share the current progress on our research into the aggregation of signatures based on curve secp256k1: There is now an early draft Bitcoin Improvement Proposal (BIP) for non-interactive half-aggregation of BIP 340 Schnorr signatures. This proposal has a variety of potential applications in the Bitcoin ecosystem. Moreover, to the best of our knowledge, this would be the first BIP with a formal specification, which is a mathematically precise description of the scheme. The formal specification can be used to prevent multiple classes of security issues and potentially help future formal software verification efforts.

Half-Aggregation

About five years ago, signature half-aggregation was first mentioned on the Bitcoin mailing list. It allows aggregating multiple Schnorr signatures into a single signature that is about half as long as the sum of the individual signatures. Importantly, this scheme is non-interactive, which means that a set of signatures can be half-aggregated by a third party without any involvement from the signers. This scheme has been discussed on and off over the years in the Bitcoin space but only recently received attention from the academic community. Chalkias, Garillot, Kondi and Nikolaenko as well as Chen and Zhao prove security under sensible assumptions, which inspired us to start writing a specification. If you want to learn more about half-aggregation, have a look at the “cross-input signature aggregation” repository or this presentation and pair-programming session.

Bitcoiners have already come up with various potential applications for half-aggregation. For example, half-aggregation can reduce the bandwidth requirement of off-chain networks that gossip BIP-340 signatures. On the other hand, half-aggregation applied to the Bitcoin consensus protocol could cut down on the size of transactions in multiple ways:

• Bitcoin script opcodes requiring multiple signatures could take a single half-aggregate signature instead.
• Transactions could have a single half-aggregate signature instead of one signature per input.
• Since half-aggregation is non-interactive, block producers could aggregate transaction signatures into a single half-aggregate signature per block.

Note that some of these ideas have complex trade-offs (which are collected here). Our draft specification only covers the cryptographic scheme and does not prescribe a particular application. While it may be useful to some off-chain protocols immediately, we intend the half-aggregation specification to aid future discussions around consensus changes.

To avoid confusion, we would also like to mention a different signature aggregation approach that provides much larger space savings. We call it full aggregation because the size of the aggregate signature is equal to a regular Schnorr signature. However, due to its complexity, full aggregation is not always preferable to half aggregation. In particular, similar to the MuSig2 multi-signature scheme, full aggregation is an interactive protocol with at least two rounds and requires securely keeping signing state. Also, it (probably) does not permit deterministic signing without adding relatively massive complications to the scheme (similar to MuSig-DN for example). Therefore, we believe that even for protocols that already require interaction, the simplicity of half-aggregation may beat the efficiency of full aggregation.

Our specification of half aggregation differs from the scheme initially discussed on the mailing list by the added capability for incremental aggregation, which we found in Chen and Zhao’s work. Incremental aggregation allows us to aggregate additional signatures into an existing half-aggregate signature. Surprisingly, this is a straightforward generalization of regular half-aggregation and does not add significant complexity to the specification.

Formal Specification

The half-aggregation BIP draft is similar in scope to BIP 340 (“BIP Schnorr”) since both specify a cryptographic scheme without particular applications. BIP 340’s specification consists of two parts, the actual specification in pseudocode and a reference implementation in python. This situation is not ideal. This situation is not ideal, primarily because the meaning of the pseudocode is not specified. The readers rely on their intuition to determine what the pseudocode is doing; this judgment may differ from reader to reader. The python reference implementation can help in case the pseudocode is unclear. Many programmers are familiar with python, and it comes with an extensive language reference. However, the reference manual describes the meaning of individual operations in natural language, which again leaves room for interpretation.

In contrast, the half-aggregation BIP draft has a formal specification. Each operation of the specification has a precisely defined meaning (semantics), which implies that the overall behavior of the scheme is unambiguous. Such precision is a nice feature, but on its own may not be worth the effort. Most importantly for us, the rigorous definition of the scheme paves the way for computer-aided formal proofs.

With software tools known as proof assistants, it is possible to prove that the formal specification has certain properties, like the absence of out-of-bound array access or integer overflow. Moreover, one can formally prove completeness of the specification, i.e., applying the aggregation algorithm to valid BIP 340 signatures always yields a valid half-aggregate signature. In principle, it is also possible to prove the security of the specified scheme using proof assistants. In the case of half-aggregation, this would be a relevant and ambitious research project.

Proving theorems about specifications is especially valuable because the behavior of specifications is often not identical to the abstract mathematical scheme they are based on. In fact, the security properties of the abstract scheme may not survive translation to a specification, leading to critical vulnerabilities. This problem can be circumvented if the proofs apply directly to the specification.

A formal specification is also a necessary prerequisite to do formal verification, which is the process of proving that the behavior of an implementation matches that of the specification. This allows for writing a highly optimized implementation and then formally verifying it against a specification. If the specification is correct, then the implementation is also correct, and proofs about the specification carry over.

Implementations that are supposed to undergo formal verification are generally not written in common programming languages. Instead, implementers use languages like Verifiable C or F* and its ecosystem.

The formal specification language we use for half-aggregation is hacspec. One of its most compelling features is that it is embedded in rust: hacspec specifications are also valid rust code. So one can build, run, manage dependencies and test the specification like any other rust project. Thus, the specification can also serve as a reference implementation and remove the need to add extra python code as in BIP 340. A downside is that readers of the BIP may not be as familiar with rust as with python. Additionally, hacspec code does not necessarily look like idiomatic rust and misses some primitives and rust standard library components. To help readers of the half-aggregation BIP draft, we also included informal pseudocode, which is similar in syntax and semantics to BIP 340’s pseudocode. For the kind of theorem proving and software verification mentioned above, the hacspec typechecker program can translate hacspec code into specialized languages like Coq, F*, and EasyCrypt, which are starting points for proof engineering.

Conclusion

Half-aggregation of BIP 340 signatures has potential applications in various scenarios. We hope our half-aggregation BIP draft can serve as a valuable foundation for further exploration. We invite you to review the draft and provide feedback. What do you think about the absence of a python reference implementation and adding a formal specification written in hacspec? Besides being a fun experiment, we believe this is a promising direction that has the potential to advance the robustness of the Bitcoin ecosystem significantly.

Note: This blog was originally posted at https://blog.blockstream.com/half-aggregation-of-bip-340-signatures/

Half-Aggregation of BIP 340 Signatures was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Grubles

The Bitcoin blockchain is a record of all bitcoin transactions that have occurred over time, from the genesis block in 2009 to now. The first step in utilizing this public ledger and sending bitcoin across the network, is creating a wallet and funding it with some bitcoin.

A wallet is simply a file on your computer or mobile phone that contains private keys generated by your Bitcoin wallet app. These private keys are much like passwords and are meant to be kept completely secret. Only a wallet’s true owner should be able to access the private keys, as the keys allow anyone in their possession to send funds around in the Bitcoin network.

Thus, it’s essential to secure access to private keys and make sure they are backed-up. Losing the keys means losing access to your funds!

With this in mind, it’s easy to want to delegate securing private keys (and therefore your funds) to a third party such as an exchange or custodian out of fear of mishandling. Rest assured — it’s never been easier to hold your own Bitcoin keys with Blockstream Green’s Multisig Shield.

Wield your own Bitcoin keys

Learn about self-custody and how to set up a Bitcoin wallet with the latest episode of our Deciphered video series.

When in control of your private keys, you’re able to send bitcoin to anyone you wish, at any time of day. You can also receive bitcoin from anyone. No one can stop you. That’s part of what makes Bitcoin so great — the freedom that you gain by using it. There’s no third party service inquiring why you paid your friend back for dinner, as an example.

In this sense, controlling your keys is much like having physical cash in your wallet. Except with Bitcoin, you can teleport your money anywhere, to anyone, thanks to the power of the Bitcoin network.

Having someone else be in control of your Bitcoin private keys strips away every advantage of using Bitcoin. Since someone else is in control, you now require permission from them to do anything with your funds. We can do better!

What if you could control your bitcoin and have the peace of mind knowing your funds are secure? Enter Blockstream Green and its Multisig Shield technology.

Shields up

Blockstream Green is a Bitcoin wallet app carefully designed to make it easy to control your own private keys. Green also supports the Liquid Network, a Bitcoin sidechain and layer-2 solution built for fast transfers of stablecoins, security tokens, and other unique issued assets. One of Green’s most powerful features is its Multisig Shield technology, which works on both Bitcoin and Liquid networks.

Multisig Shield is built using Bitcoin’s native multisignature transaction technology. Multisig transactions in Bitcoin require more than one person to cryptographically sign. Without meeting the threshold of signatures, the transaction cannot be sent on the Bitcoin network. Only once all parties have signed the transaction can it be finally sent.

This makes it harder for hackers to steal your bitcoin since they now have to hack two or more separate devices instead of just one.

Multisig Shield is designed so one key is stored on your desktop or mobile device, and one key is stored on our remote infrastructure. This means the difficulty of stealing your bitcoin rises dramatically compared to typical single-signature Bitcoin wallets. To make it even more difficult, the key on our remote infrastructure is only activated when you pass a chosen two-factor authentication (2FA) method.

You have a few options to choose from for your 2FA method:

• SMS
• Email
• Phone call
• Authenticator app / TOTP

We highly recommend the Authenticator app / TOTP method due to SIM swapping attacks and the added privacy benefit of not having sensitive information about your transactions sent via email.

Singlesig wallets

If you would prefer to have a single signature Bitcoin or Liquid wallet, Green can also accommodate you. Singlesig wallets give you full control over your private keys just like Multisig Shield wallets, but could be considered less secure since you’re relying strictly on the security of your mobile device or hardware wallet.

An advantage to using singlesig wallets is their interoperability with other Bitcoin wallet apps. You can take a singlesig recovery phrase generated by Blockstream Green and import it into other wallet apps if you wish.

Fortify your Bitcoin

Hardware wallets are a great way to add an additional layer of security for your Bitcoin wallet. They’re specifically engineered for Bitcoin and are super simple to use.

Our purely open-source Bitcoin and Liquid hardware wallet, Blockstream Jade, works in tandem with the Green app to generate and store private keys so you don’t have to store them on less secure devices connected to the internet.

We recently detail the security tech packed into Blockstream Jade, including technology like Bitcoin Core-inspired randomness, a blind PIN server, and Anti-Exfil that work together to keep hackers from running away with your money.

Blockstream Jades are affordable and are a no-brainer for a Multisig Shield wallet. We recommend adding a Jade into your wallet setup. Here’s how:

1. Purchase a Jade on the Blockstream Store for only $45.99
2. Follow the instructions for your platform (iOS, Android, desktop)
3. Fund your new Bitcoin or Liquid wallet
4. Rest easy

Continue your self-custody journey

Now that you’ve taken control over your precious bitcoin with Blockstream Green, learn how to use coin control with your new Bitcoin wallet.

Once you’re ready, stop by the Blockstream Green Community Telegram group to chat about all things Bitcoin, multisig wallets, and improving your privacy with coin control.

Be sure to subscribe to the Blockstream YouTube channel to catch the latest Deciphered episodes too!

Blockstream Green: Bitcoin Self-Custody was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Grubles

Blockstream Green is built from the ground up to provide industry-leading security and user experience. Green is the easiest way to secure your bitcoin and Liquid Network assets with multisignature technology, a key (pun intended!) feature in Bitcoin and the Liquid Network that allows you to program your assets to require sign-off from multiple independent keys in order for funds to be transferred.

This means you can eliminate single points of failure that can lead to theft. A hacker would need to compromise the wallet on your device and the remote infrastructure storing the second key used in the multisignature wallet. Green also supports standard single signature Bitcoin and Liquid wallets, and hardware wallets from Trezor, Ledger, and of course our own hardware wallet Blockstream Jade.

A new feature we’ve recently added to Green is called Coin Control.

What is Coin Control?

Check out our new Bitcoin tech video explainer series Deciphered

To understand what Coin Control is, we need a short overview on how transactions work on Bitcoin.

Bitcoin and Liquid use an Unspent Transaction Output (UTXO) model for their transactions. Bitcoins are created through the mining process and start their life on what are called coinbase outputs. These coins have no history since they are completely new and unspent. When a miner spends those coins to a new address, they become inputs to the transaction that sends them to the new address (the output).

This process continues indefinitely as coins are sent to new owners over time. The current ledger of who currently owns which coins is called the unspent transaction output set, or UTXO set.

A transaction is simply a declaration of which of your coins you want to spend to which specific addresses. Much like if you were to sign a document stating you want to send Bob $100 from your ACME Bank account.

If you want to send a specific amount to someone, your wallet will automatically create a change address that it uses to send the remaining coins you have left over after deducting the amount sent to the recipient. The change address will become an output in the transaction along with the recipient’s address.

The Bitcoin network is transparent, meaning everyone can see everyone else’s transactions. This means that when someone sends you some bitcoin, and you want to consolidate that into the rest of your holdings, then you might reveal your entire bitcoin holdings to them unintentionally. This is where Coin Control comes in handy.

Coin Control allows you to individually select specific outputs to use as inputs in a transaction. Maybe you don’t want your local coffee shop to know how much bitcoin you spend at the grocery store and vice versa. Or you don’t want your colleague to know how much bitcoin you have after covering for dinner. Using Coin Control, you can label and segregate your funds without consolidating accidentally and harming your financial privacy.

Dust Attacks

Blockstream Green also protects you from a specific technique that is used to harm the privacy of users’ wallets called a “dust attack”. A dust attack is when an attacker sends a very small amount of bitcoin to one of your addresses hoping you will consolidate that output into your larger holdings.

Consolidating this output reveals to the attacker how much bitcoin you truly own. Green automatically detects these attacks and labels the “dust” outputs so you don’t accidentally commingle them into your larger bitcoin stack.

How to use Coin Control in Green

Now that you’ve learned how a Bitcoin wallet manages its bitcoin and what Bitcoin transactions are, get started using Coin Control in the latest Blockstream Green release.

• Set up a Bitcoin wallet with Blockstream Green
• Learn how to use Coin Control with your new Bitcoin wallet

Once you’re ready, stop by the Blockstream Green Community Telegram group to chat about all things Bitcoin, multisig wallets, and improving your privacy with Coin Control.

Be sure to subscribe to the Blockstream YouTube channel to catch the latest Deciphered episodes too!

Blockstream Green: Coin Control was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Making Bitcoin and Liquid more private and more efficient is a fundamental goal of our research efforts at Blockstream Research. One particular way to achieve this goal is to make transactions of different kinds look as similar as possible on the blockchain: if it is not possible to distinguish transactions from multisig wallets, the Lightning Network, and other Layer 2 applications from regular payments, then it is much harder to analyze blockchain data and track the payments of users.

Our past contributions towards this goal include MuSig, MuSig-DN, and MuSig2, which allow expressing “n-of-n” multisig wallets (2-of-2, 3-of-3, …) with just a single BIP340 (Schnorr signature) public key that appears as if the wallet only consists of a single user who makes a regular on-chain payment. To achieve similar efficiency and privacy benefits for “t-of-n” multisig wallets (1-of-2, 2-of-3, 3-of-5, …), Chelsea Komlo (University of Waterloo and Zcash Foundation) and Ian Goldberg (University of Waterloo) proposed the FROST threshold signature scheme.

“t-of-n” multisig wallets are at the heart of Blockstream’s Liquid Network, which is a sidechain run by a distributed federation of functionaries. In particular, the functionaries are responsible for the operation of a federated wallet, which currently uses an “11-of-15” multisig and holds the bitcoins that have been pegged-in, i.e., transferred to the sidechain. Whenever a Liquid user would like to peg-out, i.e., transfer Liquid bitcoin (L-BTC) back to the Bitcoin main chain, the federation creates a transaction that sends bitcoin from the federated wallet to the user’s address. Bitcoin’s built-in support for 11-of-15 requires broadcasting all 15 public keys and all 11 signatures, which results in high fees. Using the FROST protocol would solve this issue. However, in order to sign the transaction with FROST, a quorum of 11 functionaries must coordinate and exchange multiple messages. If coordination fails, e.g., because network conditions are poor, a signer is offline, or actively disruptive, the protocol fails and must be restarted. This is suboptimal for automated signing software as used in the federated wallet because it would not reliably produce a signature even if a quorum of at least 11 signers is willing to sign.

ROAST (RObust Asynchronous Schnorr Threshold signatures) is our solution to this problem. ROAST is a simple wrapper around threshold signature schemes like FROST. It guarantees that a quorum of honest signers, e.g., the Liquid functionaries, can always obtain a valid signature even in the presence of disruptive signers when network connections have arbitrarily high latency. Our empirical performance evaluation shows that ROAST scales well to large signer groups, e.g., a 67-of-100 setup with the coordinator and signers on different continents. Even with 33 malicious signers that try to block signing attempts (e.g. by sending invalid responses or by not responding at all), the 67 honest signers can successfully produce a signature within a few seconds. For a more in-depth introduction and description of the protocol, read the full paper.

ROAST is a result of a research collaboration between Tim Ruffing (Blockstream), Viktoria Ronge (Friedrich-Alexander-Universität Erlangen-Nürnberg), Elliott Jin (Blockstream), Jonas Schneider-Bensch (CISPA Helmholtz Center for Information Security), and Dominique Schröder (Friedrich-Alexander-Universität Erlangen-Nürnberg).

We close with an excerpt from the paper, the tale of Frostland, which illustrates the communication steps required for FROST and the intuition behind ROAST.

Frostland

In the far country of Frostland, a democratic council is responsible for legislation. The constitution states that for a new bill to pass, a majority of t = 7 of n = 13 council members need to sign it. Readers not familiar with the Frostlandic culture might assume that the main difficulty in the democratic process is finding a majority in the council and that signing the bill is only a formality.

However, in Frostland, signing is a complicated task. Frostlanders are very proud of their aesthetic heritage. Each of the 13 council members owns a unique and beautiful watermark, and a bill is only valid if the paper it’s written on carries the watermarks of all signers (and no others).

The signing process is, therefore, as follows: Find a majority coalition of council members, manufacture a sufficient amount of paper carrying the watermarks of these council members (but no other council members’ watermarks), write the contents of the bill on the watermarked paper, and finally, collect signatures on the bill from exactly those members. However, if one of the members of the coalition fails to provide a signature during the final step, e.g., because she is out of the office for an indefinite period of time, the process stalls. In particular, it is not possible to ask another member to sign because the paper carries the disruptive member’s watermark (instead of the new member’s watermark). The only way to move forward is to start an entirely new signing process from scratch, which involves finding a new majority of council members and going through the cumbersome process of manufacturing paper with a new set of watermarks.

This peculiarity makes signing very complicated, and the council members employ a secretary whose task is to facilitate the process. Unfortunately for the secretary, it is not clear upfront which council members support a proposed bill. From time to time, members try to disrupt the signing process in an attempt to prevent other members from passing the bill and refuse to sign even though they have indicated support for a bill. In the worst case, it could even happen that all 13 council members claim to support the bill, but in fact, only 7 or fewer of them support it.

The poor secretary has multiple options: First, the secretary could choose a group of 7 council members who claim to support the bill, manufacture paper with their watermarks, prepare a single copy of the bill on that paper, and ask the chosen group to sign that copy. If any council members in the chosen group actively refuses to sign correctly (e.g., by giving a wrong signature) and thereby forces the signing to abort, the secretary can identify the disruptive members, fret about the dishonesty in the council, replace the disruptive members with other members, and prepare a new copy of the bill (which involves manufacturing new paper with different watermarks). However, the very bureaucratic rules in the constitution of Frostland mandate that each council member is given an indefinite amount of time to check a bill before signing or refusing it, and as a result, the entire signing procedure can take very long. Some particularly annoying council members sit in front of the bill for hours and hours, pretending to check that the copy has been prepared correctly, and the secretary cannot tell whether a given member will eventually sign or just keep sitting there forever. As a result, this procedure can take very long and even get stuck.

Alternatively, the secretary could prepare a separate copy of the bill for each group of 7 members and ask all supporting council members to sign each copy on which their watermark appears. While this procedure is guaranteed not to get stuck, the secretary, who is proficient in combinatorics, knows that the procedure is not suitable in practice because it requires him to prepare “n choose t” = “13 choose 7” = 1716 copies in total.

As a solution to this problem, the secretary uses the following procedure: In the beginning, all council members that signal support for the bill are asked to gather in the council building. The secretary maintains a list of all these members and whenever there are at least 7 members on the list (which is also the case in the beginning of the procedure), he calls a group of 7 members to his office, and strikes out their names on the list. He then obtains paper with the watermarks of those 7 members, writes a copy of the bill on that paper, and asks the council members in the group to sign it. Whenever a council member has completed signing the copy, they leave the office and wait for a new call while the secretary adds their name back to his list.

It is easy for the secretary to see that this procedure will succeed and not need too many copies of the bill: If at least 7 council members actually support the bill and behave honestly, then at any point in time, he knows that these 7 members will eventually sign their currently assigned copy and be re-added to the secretary’s list. Thus the secretary can always be sure that 7 members will be on his list again at some point in the future, and so the signing procedure will not get stuck. Moreover, since members are assigned a new copy only after correctly signing the previously assigned copy, each member can hold up the signing of at most one copy at a time. Thus, even the maximum of n − t = 13 − 7 = 6 disruptive council members can hold up the signing of at most 6 copies. At the very latest, the 7th copy of the bill will then be assigned only to honest council members who will complete the signing and produce a correctly signed bill.

ROAST: Robust Asynchronous Schnorr Threshold Signatures was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jade may be small, but it packs a ton of tech to make sure your Bitcoin keys are secure.

By Grubles

The ability to self-custody assets is an important aspect of Bitcoin and the Liquid Network. Holding your own keys has become quite popular thanks to the honorable efforts of Bitcoin-focused educators. Due to this, a flourishing market of hardware wallet devices has emerged over time, using many different techniques for securing users’ precious private keys.

Jade is Blockstream’s take on hardware wallets and is unique in its approach of using inexpensive commonplace hardware, developer-friendly FOSS firmware, and open source infrastructure to separate security-related components. So, what innovations have we introduced in Jade? In this multi-part blog series, we jump straight into the lower-level mechanisms that protect your bitcoin and Liquid Network assets. There’s too much to fit into a single post!

This first post touches on how Blockstream Jade derives randomness from its internal sensors and other sources (so your private keys are truly unique), how Jade prevents certain subtle attacks that can lead to loss of funds, and how we leverage a blind server to securely lock out a potential thief given a number of failed PIN attempts.

Bitcoin Core-Inspired Randomness

Private keys require strong randomness to avoid loss of funds. Attackers can grind private keys and search for weakly-generated ones, hoping to steal funds that land on the corresponding addresses. Jade uses a multi-faceted approach to ensure your private keys have sufficient randomness to prevent this type of attack.

While Jade is running, entropy is generated from various independent sources and sensors:

• User input
• CPU counters
• Battery state
• Ambient temperature
• Built-in cryptographic-strength hardware number generator
• Entropy from the Blockstream Green companion app

The built-in hardware cryptographic random number generator (CRNG) derives entropy from various sources, one of which is the included radio (used for Bluetooth). When the radio is disabled with the optional “noradio” firmware (selectable in the Green companion app), the CRNG loses that source and, therefore, has reduced entropy. To mitigate this, we use an ESP32 API call named “bootloader_random_enable()” to sample raw radio noise only during boot, which is then added to the entropy pool along with the sources mentioned above.

Blind PIN Server

When a Jade is first initialized, many different components work together to ensure that your private key data is truly random, encrypted, and stored securely:

• Entropy pool
• Blind PIN server
• Encrypted flash storage
• Secure boot

At first boot, a Jade prompts the user to choose a unique PIN. This PIN is used in combination with a blind PIN server to encrypt your Jade’s key material. The Blockstream Green companion app passes messages between the Jade and the PIN server, but is blind to the data communicated since it is encrypted. The Jade itself does not communicate with the blind PIN server.

To prevent physical attacks on a stolen Jade from extracting / stealing coins, the seed is encrypted with random keys split between the Jade device and a lock-out server.

This process works in more detail as follows: once the PIN is chosen, an ephemeral Elliptic Curve Diffie Hellman exchange (ECDH) exchange occurs with the remote server. An ECDH key exchange allows two separate entities with no previous knowledge of each other to generate a shared secret over public insecure channels. Using a known public key of the blind PIN server, an ECDH key exchange occurs, and the communications channel can be fully encrypted. Once the encrypted channel is established, the Jade and the remote server work together to create an AES256 key.

When creating a new wallet recovery phrase, entropy is gathered from the pool described earlier and the resulting key material used for the recovery phrase is encrypted using the AES256 key. This data can only be decrypted when the user inputs the correct PIN on the Jade and establishes a connection with the remote PIN server, mediated by the companion app (e.g. Green). Since the server only has a part of the AES256 key, it is blinded to any of your wallet’s keys and the PIN used on the Jade. All data at rest is encrypted on the server.

The newly-encrypted key material is then stored on the encrypted off-chip flash of the Jade and protected by Secure Boot. Secure Boot is a technology that prevents unsigned boot firmware from running on your Jade, such as a compromised firmware image from an attacker. It ensures that only firmware you intend to run is used to boot the device.

To conclude, the Jade now has a strongly-encrypted recovery phrase. An attacker would need to compromise both the local encrypted flash on the Jade and the remote PIN server in order to access the recovery phrase.

Anti-Exfil

Building off the entropy pool we’ve generated using the various inputs the Jade provides, this feature prevents a nasty undetectable attack that compromised hardware wallets can launch against their own users. We’ve blogged in-depth previously about this attack and mitigation if you’d like to read more. To summarize, a compromised hardware wallet can slowly leak the user’s private key(s) through the signatures it creates, despite the private key being generated with strong randomness.

To understand how the attack and mitigation works, we need a very short overview on how signatures work in Bitcoin.

With ECDSA, the digital signature algorithm used in Bitcoin (along with Schnorr now), a random private key is combined with a nonce, which is a one-time value intended to add randomness to the signature to ultimately produce a transaction signature that can be validated by other users’ Bitcoin full nodes. Anyone can guess your private key based on your signatures without this random nonce, which is as bad as it sounds!

Compromised hardware wallets could create a nonce that appears random but is not. The nonces could be known to an attacker ahead of time. Even worse, the hardware wallet could leak parts of the user’s master private key into individual nonces, which would allow the attacker to guess every private key given a sufficient number of signatures.

Anti-Exfil uses “sign-to-contract” to ask Jade to use its signature nonce while cryptographically committing to some random data proposed by the (assumed uncompromised) host computer. The random data’s hash is then combined with the signature nonce to produce the signature.

By use of this protocol, the nonce is re-randomized, thus preventing the attack. We’ve implemented Anti-Exfil into the Jade firmware as of version 0.1.24 (April 14, 2021).

More Jade to Follow

This concludes the first part of our tech overview series on Blockstream Jade. Keep an eye on our Engineering Blog (and take a look at the other posts there!) for the next post in the series.

If you want to get your hands on a Jade, we offer them on our Blockstream Store for only $45.99. Pay with on-chain BTC, Lightning, or use the Liquid Network and pay with L-BTC and USDt (and get a 10% discount). Join the Jade Telegram group to chat about all things Jade and hardware wallets too!

Blockstream Jade Tech Overview Part 1 was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

It took a bit longer than expected, but it’s finally here: Core Lightning v0.11.0 (codename Simon’s Carefully Chosen Release Name) brings new features, fixes, and performance enhancements. Over the last five months, a record number of 36 developers, half of whom are first-time contributors, have spent countless hours writing code, debugging, and triaging issues. While we can’t enumerate every single contribution here, we’re grateful for the community that has formed around this project.

So without further ado, let’s answer the question on everyone’s mind, “what’s new?”:

• Channel multiplexing: while previously CLN would only support a single active channel with a peer, we now added support for channel multiplexing, allowing any number of parallel channels running over a single peer-to-peer connection.
• Networked RPC interface: a gRPC interface enables secure remote access to the API exposed by CLN.

On top of these, we had many other features, large and small, some of which we’ll touch on below.

Channel Multiplexing

You asked for it, and we listened! You can now open multiple parallel channels to a single peer, and they can be managed completely independently. This, alongside our existing dual-funding and the upcoming splicing support, gives node operators yet another option to optimally allocate funds to channels. This meant rearchitecting a lot of the internals of CLN, but Rusty managed to pull it off in record time.

Reworking the way that we handle communication internally also gave us a chance to rethink and correct inefficiencies, avoid duplicate work, and address corner cases, resulting in a much leaner, more efficient implementation overall.

There’s even slightly intelligent use of redundant channels: if a payment requests one channel, we’ll see if there’s an alternative to that same peer which has identical fees but more capacity, and use that instead.

cln-grpc: Secure Networked RPC Interface

Another big feature users have been asking for is a standardized API that apps, plugins, and other tools could use to interact with CLN. We always had a JSON-RPC, with a very exhaustive API, but it was exposed only locally over a Unix-domain socket. Some plugins chose to re-expose the API over a variety of protocols, ranging from REST to gRPC, but it was additional work to install them.

So with v0.11.0, we released a new interface: cln-grpc, a Rust-based plugin that exposes the existing interface over the network in a secure manner. The gRPC API is automatically generated from our existing JSON-RPC API, so it has the same low-level and high-level access that app devs are accustomed to but uses a more efficient binary encoding where possible and is secured via mutual TLS authentication.

To use it, just add the --grpc-port option, and it’ll automatically start alongside CLN and generate the appropriate mTLS certificates. To use the gRPC interface, copy the client key and certificate, generate your client bindings from the protobuf definition and connect to the port you specified earlier.

While all previous built-in plugins were written in C, the cln-grpc plugin is written in Rust, a language that will be much more prominent in the project going forward. In order to kick off the use of Rust, we also built a number of crates:

• cln-rpc: native bindings to the JSON-RPC interface, used for things running on the same system as CLN.
• cln-plugin: a library that facilitates the creation of plugins in Rust, with async/await support, for low-footprint plugins.
• cln-grpc: of course, the library used to create the gRPC plugin can also be used directly as a client library.

All of these crates are published on crates.io and will be maintained as part of the project moving forward.

Other Features

As mentioned earlier, there are far too many changes to highlight them all here. However, we do have some other exciting features that are worth sharing now.

As part of the onion messages proposal, CLN now implements both the second and third draft of the proposal, with v3 being used for our own messages, and v2 being supported for backward compatibility when forwarding and receiving. We’d like to thank the other teams for participating in the discussion and moving the proposal forward.

After almost two years, we are finally retiring the old legacypay command. This command implemented the old non-MPP pay behavior and was introduced in v0.9.0. Not having to support this old command, allowed us to simplify the codebase and start working on more advanced implementations. More on this soon.

And finally, we’ve had support for backup plugins and replicated databases via the postgresql driver for a long time, but this release adds yet another option: native sqlite3 replication. By specifying --wallet=sqlite3://dbA.db:/second/drive/dbB.db CLN will now write to both dbA.db and /second/drive/dbB.db in parallel, ensuring that if one drive crashes, the other one has a perfect copy to recover from.

To Be Continued…

We’ve managed to squeeze a lot into this release, but we’re just getting started. As you read through the details, know that we’re already regrouping for the next release, and have quite a few more features in the works.

To update to the latest version of CLN, head over to the release page, or if you want to dig into the finer points, check out the changelog, and tell us what you like or what we could improve.

And as always, a huge thanks to the many contributors and volunteers that continue to help us improve CLN over time. We’re grateful for your contributions and look forward to continuing to partner with you in building Lightning.

Core Lightning v0.11.0: Channel Multiplexing, a New API, and Much More was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lightning, at a high level, is ultimately just software running on a group of online computers to form a network. Users are free to join and leave the network with their own individual nodes, much like how they can for the underlying consensus layer — Bitcoin. Lightning node software is written in a variety of programming languages and is typically portable to many different operating systems and CPU architectures. Nodes are connected to the internet and manage hot bitcoin wallets, so the underlying software and hardware is important for keeping private keys safe.

Core Lightning (CLN) is one of the handful of Lightning node implementations and runs on practically any *nix operating system, as well as Windows using WSL. CLN can also be built and run on different CPU architectures like x86, POWER, RISC-V, and ARM too.

Choosing which software and hardware to use for a Lightning Network node can be pretty daunting. Should you use an old Thinkpad? Raspberry Pi? A used rackmount server? Ubuntu? FreeBSD? Windows?

Each choice you make has trade-offs in terms of openness (e.g. closed source firmware), software support, compute ability, power usage, data integrity, and even noise (1U fans are LOUD).

For this article, we’ll explore the ideal combination of hardware and software for a home-based routing node. Let’s go over some of the hardware options.

Consumer Hardware

Typical desktop and laptop hardware fall under this category. Most desktops are actually fairly decent for running a LN routing node since you can add more storage devices and potentially create a RAID array, but they tend to lack ECC memory support unless you opt for more expensive workstation / enterprisey options. Consumer desktop hardware also lacks open firmware options unless you go the route of manually flashing your chips, which can backfire and brick your hardware.

Laptops are okay since they have some fault tolerance given the batteries, but they lack the IO to have redundant storage and the ECC memory support — although there are a handful of models that do have ECC strangely…

Consumer hardware can be cheap (e.g., Raspberry Pis), but not include things like proper IO, ECC memory support, or firmware auditability which I think are essential for an online computer managing hot private keys.

Rack Hardware

Rackmount hardware is a crapshoot. You can pick up pretty decent decommissioned enterprise units off of eBay, but they’ll be either expensive, loud, partly broken, lacking hardware or IO, include closed firmware, or some combination of those things. Of course, you can build your own, but that can become expensive, and there is a sad lack of open firmware options.

99% of the time, the ebay rackmount units will have LOUD high-RPM fans that penetrate drywall and can be heard throughout your home, so that’s something you’ll appreciate learning before pulling the trigger on buying one.

Having touched briefly on some of the (IMO not great) options available for running a LN node, here’s a list of hardware and software components that seem ideal to me.

I believe this hardware/software list is well-balanced for price, openness, data integrity, reliability, power usage, and compute ability. I don’t list off less important hardware like the computer case or power supply, but the general rule is don’t cheap out.

Ideal Hardware

SynQuacer Linaro96board

CPU: 24-core ARM Cortex-A53
RAM: 32 GB of ECC DDR4 (included with mobo purchase!)
IO: three PCIe slots and two SATA ports
Power usage: ~35 watts with 32 GB RAM, 4x SATA SSDs
Cost: ~$415 US

This ARM board is pretty exceptional for a Lightning node for many different reasons:

Many Cores

The ARM Cortex-A53 is extremely popular and has been used in cheaper SoCs like the Raspberry Pi 3. The difference with this board is there are 24 A53 cores instead of the usual four, which lets you run a larger LN node with many open channels. I’ve tested 100+ channels while running the CLBOSS plugin. ARM is now ubiquitous, too, with excellent software support among operating systems, and especially in the Bitcoin software ecosystem. There are also some security benefits to using ARM over x86 that I won’t go into detail here but are related to SPECTRE and other architectural flaws in x86 processors.

Safe Memory

One of the most important components of this motherboard is the ECC memory support. Without ECC, bad things can happen. ECC memory ensures the integrity of your important Lightning data, so bit rot and other harmful things can’t permanently corrupt your data and cause funds loss. The board includes 32 GB of ECC DDR4 memory with purchase, which is pretty awesome! That is plenty for a CLN node.

Plenty of IO

With two SATA ports and three PCIe slots, you can easily build an array of disks for storage, whether it’s using software RAID, ZFS, BTRFS or whatever you’re comfortable with. You can’t do that with an RPi! Well, not easily, I guess.

The combination of ECC memory and the ability to have redundant storage (which doesn’t rely on flaky USB) makes this board an excellent choice for any use case that requires data integrity — including running a Lightning node.

Power Efficiency

By running this SynQuacer board with e.g. four SSDs and 32 GB of memory you can reach a whopping ~35 watts of power draw. This means you’ll save on your power bill and keep more of your earnings from routing compared to other CPU architectures like x86 and POWER.

Auditable Firmware

One of the primary reasons for choosing this board is its open firmware. Inspect the board’s firmware, compile it yourself, and install it. Good luck doing that with 99% of other available platforms.

Build Source for Developerbox

Storage Hardware

For storage, go SSD. Samsung makes excellent SSD s— particularly their Pro models. Buy a few depending on your budget and set up a mirror, so data is duplicated to the devices. Don’t go overboard with complicated setups. We just need duplication and device failure tolerance. For a multi-device storage array, you will likely need a PCIe SATA adapter to run more SSDs.

Ideal Software

Operating System

Choose a good *nix such as Ubuntu, Debian, Fedora, or a BSD like FreeBSD. What matters most is your familiarity with the OS you choose. CLN and related software runs best on *nix, so I would definitely advise against running a routing node on Windows or macOS.

Lightning Node Implementation

I’m partial to Core Lightning since it’s designed to be modular, performant, and resource-efficient, and that’s important for limited systems (practically any ARM device). Most importantly, its developers focus on specification compliance, which means your routing node can interoperate with other implementations on the Lightning Network.

Plugins let you customize your CLN node with the amount of functionality (read: complexity) you can tolerate. You can run a minimal node or not; it’s up to the user!

CLN Plugins

If you opt for adding plugins to your node, these are a couple I recommend.

• CLBOSS: Fully automate your CLN node
• Summary: Generate a tidy summary of your LN status, like inbound/outbound sats, msats earned, and more

There are a slew of plugins available. Many are created by the awesome community contributing to Core Lightning. Check them out!

GitHub - lightningd/plugins: Community curated plugins for core-lightning

Storage

Storage mirroring is a must. At a minimum, your CLN data directory should live on a RAID mirror with two SSDs (ideally Samsung Pro units), for better reliability and power efficiency relative to hard disk drives. Unless you’re logging with debug output firehose turned on, you won’t need much storage space. This means your storage array can be cheap. You can always compress logs too. Bitcoin blockchain data can be placed on a separate single drive. We don’t need to have it on our mirror.

Filesystem

The filesystem should be a modern one such as Ext4, XFS, or potentially ZFS or btrfs but I personally avoid these since I like to keep things as simple as possible. ZFS is an excellent project but much of the functionality would go unused in this use case. Btrfs, in my experience, is a nightmare. XFS does metadata checksumming, RAID mirroring provides hot spare(s) in case of device failure, and XFS is well-supported in the Linux kernel. Of course, if you choose FreeBSD as your node’s OS, then ZFS is basically your only choice aside from UFS.

Like the operating system choice, it’s more important for you to be familiar with the tools you use than for the tools to have fancy functionality that you can shoot your toes off with.

Backups

The Core Lightning docs include a comprehensive list of backup options for a node. Here’s a shortlist:

Mirroring
Probably the simplest and most effective route is to have a storage mirror with RAID. While some may not consider having a hot spare a “backup”, this situation is a little different since you simply cannot have long-term LN backups due to channel state needing to be constantly updated.

Remote DB
More advanced users can set up a remote device that your CLN node writes to over the network in order to save channel state. This is useful for avoiding a full local system crash — your data will at least be written to an entirely separate remote device and hopefully provide some recoverability.

Secondary DB on separate local storage
CLN also supports writing to separate local databases concurrently. As an example, this lets you plug in a USB storage device and write to it while at the same time writing to the primary storage device(s). This is similar to using a mirror, but you can mix different storage devices this way to avoid same-age / same-manufacturer device failure scenarios.

Highly sensitive CLN data is listed below. They’re located wherever you set your CLN data directory to, which is by default ~/.lightning .

• hsm_secret : This is the secret for your node’s on-chain wallet. You can back this up once and be able to recover any on-chain funds.
• lightningd.sqlite3 : This is repeatedly written to while your node is running. It contains toxic channel state that if restored incorrectly will result in a loss of funds. Be careful, and keep track of the backup date so you don’t restore old toxic channel state accidentally.

Ideal Extras

Uninterruptible Power Supply

Outfit your CLN node with a UPS in case there are power outages. These outages can cause data corruption, which is our primary enemy when running a LN node.

Connectivity

Research ISP options in your local area and pick the most reliable. No matter what you pick, residential ISPs will bring down your home connection for maintenance from time to time. Lightning is designed to be fairly resistant against temporary outages, but it’s best to have a backup just in case.

Cell networks have high reliability considering their usage by emergency services. Spend some time researching how you can leverage mobile device tethering in case your main ISP goes offline. Or you can have a dedicated 4G antenna setup for redundancy.

Node Privacy

Using a VPN to hide your home IP address is also a good idea. A cheap $5 Digitalocean or Vultr VPS and Warren Togami’s guide will get you set up. This will allow you to run a LN node from home but use the VPS’s IP address as the IP you announce to other LN nodes. Avoid running over Tor as that introduces too much latency for payments, causing them to fail and ruin your chance at collecting a forwarding fee.

GitHub - wtogami/vpn-nat-service-forwarding-howto: VPN NAT Service Forwarding HOWTO

So that basically sums it up! This seems like a pretty good setup for a Lightning routing node running at home. It’s relatively cost-effective compared to other options while providing pretty strong data integrity that cheaper options lack. See you on the Lightning Network!

Please join me on the Core Lightning Telegram group if you want to chat more about this! See you there!

Core Lightning

Interested in contributing to Core Lightning? Take a look at the Github repo!

GitHub - ElementsProject/lightning: c-lightning - a Lightning Network implementation in C

Build a Pretty Good Lightning Network Node was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lightning is a micropayments network built on top of Bitcoin. It’s pretty great, and it lets you send bitcoin around instantaneously instead of waiting around for a block to be mined. Lightning elevates Bitcoin into a new paradigm of trustless digital cash that can not be achieved purely with on-chain transactions, with all of the limitations blockchains bring along with them.

Scalability, privacy, programmability, and user experience are all things that Lightning improves. But in order to maintain the full trustlessness of Lightning, one has to operate a Lightning-specific node in addition to a Bitcoin consensus-layer node.

Let’s be honest. Running a Lightning node is not a simple endeavor. A level of knowledge from two separate disciplines is required to successfully run a LN node. First, operating a LN node requires a decent understanding of packet routing / firewalling so other nodes can connect to yours, and underlying operating system administration to keep your node secure.

On top of that, node operation requires an understanding of how the Lightning Network works.

Managing a LN node is also a fairly interactive process, meaning you have to do a lot of individual manual tasks. You have to know which peers are “good” peers to open channels to, and that in of itself is a difficult thing to accomplish. Then you have to actually open the channels. Then you have to make sure the channels remain open if they are closed by your channel counterparty for some reason. You have to manually balance your channels, and understand why you would want to balance channels in the first place. The list goes on…

Obviously, these tasks pile up and eventually become the equivalent of a part time job.

Show Your Node Who’s Boss

Enter CLBOSS, an “AI” for your c-lightning node. All of the manual Lightning tasks I mentioned earlier are automatically handled by CLBOSS so you can go about your day without having to constantly tend to your LN node.

CLBOSS is specific to c-lightning, so you’ll have to migrate from other implementations to harness its awesomeness.

Here’s what CLBOSS can do:

• Probe nodes to determine which ones to open channels to
• Open channels when fees are low and there are on-chain funds
• Adjust routing fees to be competitive with other nodes
• Perform submarine swaps via boltz.exchange API
• Automatically rebalance channels

Additionally, it can do cool things leveraging c-lightning such as opening multiple channels in a single Bitcoin transaction.

This means all you have to do is deposit some bitcoin into your c-lightning node and CLBOSS will start working on your behalf. No more tedious part time LN operator job!

Installing CLBOSS

Raspiblitz users can quickly install CLBOSS in the SETTINGS menu. Just hit spacebar when CLBOSS is selected and then hit OK.

Otherwise, a manual install is required — although it’s just the typical ./configure && make && make install. The CLBOSS Github repo README has a list of dependencies too.

GitHub - ZmnSCPxj/clboss: Automated C-Lightning Node Manager

Post-Installation

Once CLBOSS is installed, add it to your c-lightning config file:

plugin=/usr/local/bin/clboss

Restart your c-lightning node, then simply feed your node some bitcoins. Over time you will end up with a slew of balanced channels and maybe even some routing fees— depending on how much BTC you feel like putting online in a hot wallet.

That’s it! While CLBOSS does its thing, you can keep an eye on the various tasks it performs with the clboss-status command.

e.g. lightning-cli clboss-status

This will output:

• On-chain swaps CLBOSS has performed for you
• A list of high quality nodes CLBOSS has discovered via probing
• Individual peer metrics (channel age, routing attempts, fees per day, etc.)
• Other stats

Now that you’ve set up CLBOSS, you can sit back and relax knowing you have less TODOs on your plate. Thanks for reading!

Automate Lightning Node Management with CLBOSS was originally published in Blockstream Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.