This week’s newsletter describes a proposal to improve capital efficiency on LN using tunable penalties. Also included are our regular sections with summaries of top questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • ● Preventing stranded capital with multiparty channels and channel factories: John Law posted to the Lightning-Dev mailing list the summary of a paper he’s written. He describes how always-available nodes can continue using their funds to forward payments even when they share a channel with a node that’s currently unavailable (such as the user of a mobile LN wallet). This requires the use of multiparty channels, which compose well with a channel factory design he’s previously described. He also restates a known benefit of channel factories of allowing channels to be rebalanced offchain, which may also allow better use of capital. He describes how to use both benefits in the context of his previous innovation of the tunable penalty layer for LN. We’ll summarize tunable penalties, show how they can be used for multiparty channels and channel factories, and then explain Law’s new results in context.

    Alice and Bob create (but do not immediately sign) a transaction which spends 50M sats from each of them (100M total) to a funding output which will require cooperation from both of them to spend. In the diagrams below, we show confirmed transactions as shaded.

    Alice and Bob create the funding transaction

    They each also use a different output they individually control to create (but not broadcast) two state transactions, one for each of them. The first output of each state transaction pays a trivial amount (say 1,000 sat) as an input to a timelocked offchain commitment transaction. The relative timelock prevents each commitment transaction from being eligible for confirmation onchain until a certain amount of time after its parent state transaction is confirmed onchain. Each of the two commitment transactions is also funded by conflicting spends of the funding output (meaning that only one of the commitment transactions can eventually be confirmed). With all the child transactions created, the transaction which creates the funding output can be signed and broadcast.

    Alice and Bob create their commitment transactions

    Each of the commitment transactions pays to the current state of the channel. For the initial state (S0), 50M sats is refunded to each Alice and Bob (for simplicity we ignore transaction fees). Alice or Bob can start the process of unilaterally closing the channel by publishing their version of the state transaction; after the enforced delay, they can then publish the corresponding commitment transaction. For example, Alice publishes her state transaction and her commitment transaction (which pays both her and Bob); at that point, Bob can simply never spend his state transaction and instead spend the money used to create it at any later time however he would like.

    Alice spends honestly from the channel

    There are two other alternatives to unilaterally closing the channel in its initial state. First, Alice and Bob can cooperatively close the channel at any time by spending the funding transaction output (the same as is done in the current LN protocol). Second, they could update the state—for example, increasing Alice’s balance by 10M sat and decreasing Bob’s balance by the same amount. State S1 looks similar to the initial state (S0), but to enact it, the previous state is revoked by each party giving the other a witness1 for spending the first output from their respective state transactions for the previous state (S0). Neither party can use the other’s witness because the S0 state transactions don’t themselves contain witnesses yet so they can’t be broadcast.

    With multiple states available, it’s possible to accidentally or deliberately close the channel in an outdated state. For example, Bob may try to close the channel in state S0 where he had an additional 10M satoshis. To do this, Bob signs and broadcasts his state transaction for S0. Bob can’t take any further action immediately because of the timelock on the commitment transaction. During the wait, Alice detects this attempt to broadcast an outdated state and uses the witness he previously gave her to spend the first output of his state transaction, paying some or all of the penalty amount to transaction fees. Since that output is the same output Bob needs to later broadcast the commitment transaction that pays him the extra 10M sat, he will be blocked from claiming those funds if the transaction Alice creates is confirmed. With Bob blocked, Alice is the only one who can unilaterally publish the latest state onchain; alternatively, Alice and Bob can still perform a cooperative channel close at any time.

    Bob attempts to spend dishonestly from the channel but is blocked by Alice

    If Bob notices Alice attempting to spend from his outdated state transaction, he could attempt to enter in a Replace By Fee (RBF) bidding war with Alice, but that’s a case where the penalty amount being tunable is especially powerful: the penalty amount could be trivial (e.g. 1K sats, as in our example) or it could equal the amount at stake (10M sats) or it could even be larger than the entire value of the channel. The decision is entirely up to Alice and Bob to negotiate with each other when updating the channel’s state.

    One of the other advantages of the Tunable-Penalty Protocol (TPP) is that the penalty amount is paid entirely by the user who puts their outdated state transaction onchain. It doesn’t use any of the bitcoins from the shared funding transaction. This allows more than two users to safely share a TPP channel; for example, we can imagine Alice, Bob, Carol, and Dan all sharing a channel. Each of them has their own commitment transaction funded from their own state transaction:

    A channel between Alice, Bob, Carol, and Dan

    They can operate this as a multiparty channel, requiring each state be revoked by every party. Alternatively, they can use the joint funding transaction as a channel factory, creating multiple channels between pairs or multiples of users. Prior to Law’s description of this implication of the TPP last year (see Newsletter #230), it was believed practical implementation of channel factories on Bitcoin would require a mechanism like eltoo, which requires a consensus change like SIGHASH_ANYPREVOUT. TPP doesn’t require consensus changes. To keep the diagram below simple, we’ve only illustrated a single channel created in a factory of four participants; the number of states the channel participants need to manage equals the number of participants in the factory, although Law also previously described an alternative construction with a single state but a higher cost to close unilaterally.

    A channel between Alice and Bob created from a factory by Alice, Bob, Carol, and Dan

    An advantage of channel factories described in its original paper is that the parties within the factory can cooperatively rebalance their channels without creating any onchain transactions. For example, if the factory consists of Alice, Bob, Carol, and Dan, the total value of the channel between Alice and Bob can be decreased and the value of the channel between Carol and Dan can be increased by the same amount by updating the offchain factory state. Law’s TPP-based factories provide the same benefit.

    This week Law noted that factories with the ability to provide multiparty channels (which is possible with TPP) have an additional advantage: allowing capital to be used even when one channel participant is offline. For example, imagine if Alice and Bob have dedicated LN nodes that are almost always available to forward payments but Carol and Dan are casual users whose nodes are often unavailable. In an original-style channel factory, Alice has a channel with Carol ({A,C}) and a channel with Dan ({A,D}). She can’t use any of her funds in those channels when Carol and Dan are unavailable. Bob has the same problem ({B,C} and {B,D}).

    In a TPP-based factory, Alice, Bob, and Carol can open a multiparty channel together, requiring all three of them to cooperate to update its state. One of the outputs of a commitment transaction in that channel pays Carol but the other output can only be spent if Alice and Bob cooperate. When Carol is unavailable, Alice and Bob can cooperatively change the balance distribution of their joint output offchain, allowing them to make or forward LN payments if they have other LN channels. If Carol remains unavailable too long, either one of them can unilaterally put the channel onchain. The same benefits apply if Alice and Bob share a channel with Dan.

    This allows Alice and Bob to continue earning forwarding fees even when Carol and Dan are unavailable, preventing those channels from seeming unproductive. The ability to rebalance channels offchain (with no onchain fees) may also decrease the downsides for Alice and Bob of keeping their funds in a channel factory for a longer time. Together these benefits may reduce the number of onchain transactions, increase the total payment capacity of the Bitcoin network, and lower the cost to forward payments over LN.

    As of this writing, tunable penalties and Law’s various proposals for using them have not received much public discussion.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, and Bitcoin Inquisition.

  • ● Bitcoin Core #27278 begins logging by default when a header for a new block is received, unless the node is in Initial Block Download (IBD). This was inspired by multiple node operators noticing that three blocks arrived very close to each other, the later two which reorged the first block out of the best block chain. For clarity, let’s call the first block A, the block that replaced it A’, and the final block B.

    That could indicate that blocks A’ and B were created by the same miner who deliberately delayed broadcasting them until they would cause another miner’s block to become stale, denying that miner the block reward it would have ordinarily received from A—an attack known as selfish mining. The occurrence could also be a coincidence or accidental selfish mining. However, one possibility raised by developers during the investigation was that the timings may not have actually been as close as they seemed—it’s possible that Bitcoin Core didn’t request A’ until B was received since A’ by itself wasn’t enough to trigger a reorg.

    Logging the time when headers are received means that, if the situation were to repeat in the future, node operators would be able to determine when their node first learned about the existence of A’ even if it didn’t choose to download it immediately. This logging may add up to two new lines per block (although future PRs may reduce it to just one line), which was considered to be a small enough additional overhead to help detect selfish mining attacks and other problems associated with critical block relay.

  • ● Bitcoin Core #26531 adds tracepoints for monitoring events affecting the mempool using the Extended Berkeley Packet Filter (eBPF) as implemented in previous PRs (see Newsletter #133). A script is also added for using the tracepoints for monitoring mempool statistics and activity in real time.

  • ● Core Lightning #5898 updates its dependency on libwally to a more recent version (see Newsletter #238), which allows adding support for taproot, version 2 PSBT (see Newsletter #128), and affects support for LN on Elements-style sidechains.

  • ● Core Lightning #5986 updates RPCs which return values in msats to no longer include the string “msat” as part of the result. Instead, all returned values are integers. This completes a deprecation begun several releases ago, see Newsletter #206.

  • ● Eclair #2616 adds support for opportunistic zero-conf channels—if the remote peer sends the channel_ready message before the expected number of confirmations, Eclair will verify that the funding transaction was entirely created by the local node (so the remote peer can’t get a conflicting transaction confirmed) and then will allow the channel to be used.

  • ● LDK #2024 begins including route hints for channels which have been opened but which are too immature to have been publicly announced yet, such as zero-conf channels.

  • ● Rust Bitcoin #1737 adds a security reporting policy for the project.

  • ● BTCPay Server #4608 allows plugins to expose their features as an app in the BTCPay user interface.

  • ● BIPs #1425 assigns BIP93 to the codex32 scheme for encoding BIP32 recovery seeds using Shamir’s Secret Sharing Scheme (SSSS) algorithm, a checksum, and a 32-character alphabet as described in Newsletter #239.

  • ● Bitcoin Inquisition #22 adds an -annexcarrier runtime option which allows pushing from 0 to 126 bytes of data a taproot input’s annex field. The author of the PR is planning to use the feature to allow people to begin experimenting on signet with eltoo using a fork of Core Lightning.

Footnotes

  1. It isn’t important to this high-level overview to describe what the witness is, but some of the proposed benefits do depend on the details. The original Tunable Penalties protocol description suggests releasing the private key used to generate the signature for spending from the commitment transaction. It’s possible to generate private keys in a sequence where anyone who knows one key can also derive any later key (but not any earlier key). This means each time Alice revokes a later state, she can give Bob an earlier key which Bob can use to derive any later key (for an earlier state). E.g.,

    Channel state Key state
    0 MAX
    1 MAX - 1
    2 MAX - 2
    x MAX - x
    MAX 0

    This allows Bob to store all the information he needs to spend from an outdated state transaction in a very small constant amount of space (less than 100 bytes by our calculations). The information can also easily be shared with a watchtower (which does not need to be trusted, as any successful spending from an outdated state transaction will prevent an outdated commitment transaction from being published onchain. Since the funds involved in that outdated state transaction belong entirely to the party who is in breach of the protocol, there’s no security risk to outsourcing the information about spending from it). ↩