This special edition of the Optech newsletter summarizes Bitcoin's significant development throughout 2023. This is a sequel to our 2018, 2019, 2020, 2021 and 2022 wrap-ups.
January
Anthony Towns has announced the launch of Bitcoin Inquisition, a software fork of Bitcoin Core designed to be used to test the default signature for proposed soft forks and other major protocol changes. By the end of the year, it contained support for several proposals: SIGHASH_ANYPREVOUT, OP_CHECKTEMPLATEVERIFY and basic temporary anchors, opening pull requests in its repository to add support for OP_CAT, OP_VAULT, and a limit on 64-byte transactions.
ZmnSCPxj and Jesse Posner proposed swap-in-potentiam, a non-interactive way to open a Lightning Network channel that solves the challenges faced by wallets that are often offline on mobile devices. Clients can receive funds in on-chain transactions when they are offline. When the client comes back online, the transaction can receive enough confirmations that a channel can be opened immediately and securely with a pre-selected peer without any trust in that peer. Within a few months of this proposal, at least one popular Lightning wallet used the implementation of this idea.
The standard format for wallet label exports and imports is specified as the identifier BIP329. The standard not only makes it easier to back up important wallet data that cannot be recovered from BIP32 seeds, but it also makes it easier to copy transaction metadata to non-wallet programs such as accounting software. By the end of the year, several wallets had already implemented BIP329 output.
February
Discussions began in February on Ordinals and Inscriptions, which will continue for the remainder of the year, with two related protocols for correlating meaning and data with transaction outputs. Andrew Poelstra sums up the position of many protocol developers: "There is no sensible way to prevent people from storing arbitrary data in a witness without incentivizing worse behavior and/or undermining legitimate use cases. Given that the method used by Inscriptions allows for the storage of large amounts of data, Christopher Allen suggested increasing the 83-byte limit for Bitcoin Core to store data with a OP_RETURN prefix in the output. Later that year, Peter Todd also made this suggestion.
Launched earlier this year, BitcoinSearch.xyz provides a search engine for Bitcoin technical documentation and discussions. By the end of the year, the site provided a chat interface and a summary of recent discussions.
Core Lightning adds experimental support for peer-to-peer storage backups, allowing nodes to store a small encrypted backup file for their peers. If the peer needs to reconnect later, it may request a backup file after losing data. Peers can decrypt files using keys derived from their wallets and use the file contents to restore the latest state of all their channels.
Joost Jager came up with the "high availability" flag for Lightning Network channels, allowing the channel to signal that it provides reliable payment forwarding. Christian Decker points out the challenges of creating a reputation system, such as the infrequent encounter of nodes. Another method previously proposed was also mentioned: overpayments with recycling (formerly known as boomerang or refundable overpayments), in which payments are split and sent through multiple routes, reducing the dependence on high-availability channels.
The ideas in a paper published last year became a particular focus for mitigating interference on the Lightning Network channel in 2023. In February, Carla Kirk-Cohen and co-author Clara Shikhelman began soliciting feedback on the proposed parameters used to implement one of the ideas in the paper, HTLC endorsement. In April of this year, they published a draft specification for the test plan. In July, the idea and proposal was discussed at the Lightning Network development conference, which led to some mailing list discussions discussing an alternative approach where the costs paid by both the attacker and honest users reflected the potential costs paid by node operators who provided services, so that node operators who served honest users and received a reasonable return would continue to receive a reasonable return if the attacker started using these services. In August, developers related to Eclair, Core Lightning, and LNDs announced that they were implementing parts of the HTLC endorsement agreement in order to start collecting data related to it.
Russell O'Connor and Andrew Poelstra have proposed a new BIP for backing up and restoring BIP32 mnemonics, called codex32. Similar to SLIP39, it allows the creation of multiple shares using a Shamir secret sharing scheme with configurable threshold requirements. If the attacker gets less than the threshold, then he will know nothing about the seed phrase. Unlike other recovery codes that use a list of words, CODEX32 uses the same alphabet as the BECH32 address. The main advantage of CODEX32 over existing schemes is its ability to perform all operations manually using pen, paper, instructions, and paper cutouts, including generating coded mnemonic phrases (using dice), securing mnemonic phrases with checksums, creating checksum shares, verifying checksums, and recovering mnemonic phrases. This allows users to periodically verify the integrity of a single share without relying on a trusted computing device.
March
In March, anonymous developer John Law published a paper describing a method for creating channel hierarchies for multiple users of a single on-chain transaction. The design can allow all online users to spend their funds while some of their channel counterparties are offline, which is currently not possible in the Lightning Network. This optimization will allow always-on users to use their funds more efficiently, potentially reducing costs for other users of the Lightning Network. The proposal is contingent on Law's adjustable penalty agreement, which has not seen any public software development since it was introduced in 2022.
Summary of Soft Fork Proposals 2023
James O'Beirne released a new proposal for OP_VAULT opcodes in January, followed by a draft BIP for the implementation of the Bitcoin survey in February. A few weeks later, Gregory Sanders came up with an alternative design for OP_VAULT.
The "Unify Everything" (MATT) proposal, first made last year, resurfaced this year. Salvatore Ingala shows how it provides most of the functionality of the proposed OP_VAULT opcode. Johan Torås Halseth further demonstrated how one of the opcodes in the MART proposal replicates the key functionality of the proposed opcode OP_CHECKTEMPLATEVERIFY, despite the less space-efficient version of the MATT version. Halseth also took the opportunity to introduce readers to Tapsim, a tool he had developed, which allows debugging Bitcoin transactions and Tapscript.
In June, Robin Linus described how users can lock up funds today, use them on the sidechain for long periods of time, and then allow recipients of funds on the sidechain to effectively withdraw them to Bitcoin at a later point in time, but only if Bitcoin users ultimately decide to change the consensus rules in some way. This allows users who are willing to take financial risk to start using their funds right away and get the new consensus features they want, while providing a path for those funds to return to Bitcoin's mainnet at a later date.
In August, Brandon Black proposed a OP_TXHASH version combined with OP_CHECKSIGFROMSTACK that would provide most of the functionality of OP_CHECKTEMPLATEVERIFY (CTV) and SIGHASH_ANYPREVOUT (APO) without adding too much on-chain cost to these individual proposals.
In September, John Law proposed the use of contracts to enhance the scalability of the Lightning Network. He used a structure similar to a channel factory and the proposed Ark protocol, potentially funding millions of off-chain channels that could be recycled by factory funders after expiration, and users could withdraw funds via the Lightning Network beforehand. The model allows funds to be transferred between factories without user interaction, reducing the risk of last-minute on-chain congestion and transaction fees. Anthony Towns raised concerns about the mandatory expiration flood, where the failure of large users could force many time-sensitive on-chain transactions at the same time. Law replied that he was working on a solution to delay expirations during periods of high transaction fees.
Starting in October, Steven Roose released a new draft of the OP_TXHASH opcode. The idea of opcodes has been discussed before, but this is the first specification of the idea. In addition to accurately describing how opcodes work, this article examines some of the drawbacks, such as the fact that a full node may need to hash up to a few megabytes of data each time an opcode is invoked. The BIP draft includes an example implementation of an opcode.
Also in October, Rusty Russell looked at generic contracts with minimal changes to Bitcoin's scripting language, and Ethan Heilman released a draft BIP that added a OP_CAT opcode that could connect two elements on the stack. Discussions on these two topics will continue until November.
Before the end of the year, Johan Torås Halseth also suggested that a contract-style soft fork could allow multiple HTLCs to be aggregated into a single output, allowing one party to spend everything at once if they knew all the pre-images. If one party only knows about some of these images, they can just claim those images and then return the remaining balance to the other party. This will be more efficient on-chain and may make it more difficult to perform certain types of channel jamming attacks.
April
Sergi Delgado Segura proposes an accountability mechanism for watchtowers to deal with situations where they fail to react to protocol violations that they are able to detect. For example, Alice provides a watchtower with data to detect and respond to acknowledgments of the status of old Lightning Network channels. Later, the status was confirmed, but the watchtower did not respond. Alice hopes to hold the watchtower operator accountable by publicly proving that it did not respond appropriately. Delgado proposes a crypto-accumulator-based mechanism that watchtowers can use to create commitments that users can use to generate proof of responsibility in the event of a breach at a later date.
Routing blindness, first described three years ago, was added to the Lightning Network specification in April of this year. It allows the receiver to provide the sender with the identifier of a specific forwarding node, as well as an onion-encrypted path from that node to the receiver's own node. The sender forwards the payment and encrypted path information to the selected forwarding node, which decrypts the message for the next hop, the next hop decrypts the hop that follows it, and so on until the payment reaches the recipient's node, and neither the sender nor any forwarding node can (determinately) know which node belongs to the recipient. It significantly improves the privacy of receiving funds using the Lightning Network.
BIP327 was assigned to the MuSig2 protocol in April to create scriptless multisigs. The protocol will be implemented across multiple projects and systems over the course of a year, including LND's Signrpc RPC, Lightning Lab's Loop service, BitGo's multisig service, LND's experimental simple taproot channel, and a draft BIP for extending PSBT.
Maxim Orlovsky announced the release of RGB v0.10 in April, a new version of the protocol that allows the creation and transfer of tokens (among other things) using off-chain defined and validated contracts. Changes in the state of the contract (e.g., transfers) are associated with on-chain transactions in such a way that no additional block space is used on a typical transaction and all information about the state of the contract, including its existence, can be kept completely confidential to third parties. Later this year, the Taproot Asset Protocol, which is partially derived from RGB, released a specification designed to be a BIP.
April also saw significant discussions about a proposed splicing protocol that would allow nodes to continue using channels when adding or removing funds from them. This is particularly useful for keeping funds in the channel while still allowing instant on-chain payments from that balance, allowing the wallet user interface to display a single balance to the user from which they can make on-chain or off-chain payments. By the end of the year, both Core Lightning and Eclair will support stitching.
May
A draft set of Lightning Service Provider (LSP) specifications was released in May. The standard makes it easier for clients to connect to multiple LSPs, which will prevent vendor lock-in and improve privacy. The first specification released describes an API that allows clients to purchase channels from LSPs, implementing functionality similar to liquidity advertising. The second section describes the APIs for setting up and managing just-in-time (JIT) channels.
Dan Gould has spent the better part of the year working on enhancing the Payjoin protocol, a privacy-enhancing technology that makes it more difficult for third parties to reliably link the inputs and outputs in a transaction to the payer or receiver. In February, he proposed a serverless payment protocol that could be used even if the receiver did not have an always-on HTTPS server running on a public network interface. In May, he discussed several advanced applications that use Payjoin, including various payment pass-throughs, for example, not Alice paying Bob, but Alice paying Bob's vendor (Carol), thus reducing the debt Bob owes her (or paying expected future bills upfront) – which saves block space and further improves the privacy of standard payment connections. In August of this year, he released a draft BIP on serverless payments, which does not require both the payer and receiver to be online at the same time (although each of them needs to be online at least once after the transaction is initiated before it can be broadcast). During the year, he was a major contributor to the Payjoin Development Kit (PDK) as well as the Payjoin-cli project, which provides an add-on for creating Payjoin with Bitcoin Core.
Burak Keceli has proposed a new federated pooling protocol called Ark, where Bitcoin owners can choose to use a counterparty as a co-signer for all transactions for a specific period of time. Owners can withdraw bitcoin on-chain after the timelock expires, or they can transfer bitcoin to off-chain counterparties immediately before the timelock expires. The protocol provides a trustless single-hop, one-way atomic transfer protocol for everything from the owner to the counterparty for a variety of purposes, such as mixing coins, making internal transfers, and paying Lightning Network invoices. Compared to the Lightning Network, there are increased concerns about a high on-chain footprint and the need for operators to keep large amounts of money in hot wallets. However, some developers remain enthusiastic about the proposed protocol and its potential to provide users with a simple and trustless experience.
June
Josie Baker and Ruben Somsen have published a draft BIP for silent payments, which is a reusable payment code that generates a unique on-chain address for each use, preventing output links. Output links can significantly reduce the privacy of users, including those who are not directly involved in the transaction. The draft details the benefits, pros and cons of the proposal, and how the software can use it effectively. At the Bitcoin Core PR Review Club meeting, ongoing work to implement silent payments for Bitcoin Core was also discussed.
2023 Summary Security Information Disclosure
Optech has reported three major security breaches this year:
● Milk Sad vulnerability in Libbitcoin bx: Lack of entropy in the command to create a wallet, a widely undocumented vulnerability that ultimately led to the theft of large amounts of bitcoins from multiple wallets.
● Fake Denial of Service Against Lightning Network Nodes: Matt Morehouse privately discovered and responsibly disclosed a denial-of-service attack. All affected nodes are able to update, and at the time of writing, we are not aware that the vulnerability is being exploited.
● Replacement Loop Against HTLC: A fund-stealing attack against HTLC used in the Lightning Network and other protocols was discovered privately by Antoine Riard and responsibly disclosed. Mitigations have been deployed for all of the Lightning Network implementations tracked by Optech, although the effectiveness of these mitigations is a topic of discussion, and other mitigations have been proposed.
July
The Verified Lightning Signer (VLS) project released its first beta version in July. The project allows the separation of LN nodes from the keys that control their funds. Lightning Network nodes running VLS will route the signing request to the remote signing device instead of the local key. The beta version supports CLN and LDK, Layer 1 and Layer 2 validation rules, backup and recovery capabilities, and provides reference implementations.
The Lightning Network Developers Conference held in July discussed a variety of topics, including reliable transaction confirmations at the base layer, taproot and MuSig2 channels, updated channel announcements, PTLCs and redundant overpayments, channel interference mitigation recommendations, and streamlined commitment and specification processes. Other LN discussions at the same time included cleaning up the LN specification to remove unused legacy features, and a simplified protocol for closing channels.
August
In August, support for onion messages was added to the Lightning Network specification. Onion messages allow one-way messages to be sent over a network. Like payments (HTML), messages are encrypted with onions, so each forwarding node only knows from which peer it is receiving the message from and the next peer that should receive the message. The payload of the message is also encrypted, so only the final receiver can read it. The onion message uses a blind path, which was added to the Lightning Network specification in April, and the onion message itself is also used by the proposed offer protocol.
Thomas Voegtlin has come up with a protocol that allows penalties for providers who provide users with outdated backup status. The service involves a simple mechanism where user Alice backs up data with a version number and signature to Bob. Bob adds a nonce and submits the full data with a timestamp signature. If Bob provides out-of-date data, Alice can generate a fraud certificate that Bob has previously signed a higher version number. This mechanism is not unique to Bitcoin, but combined with certain Bitcoin opcodes can make it available on-chain. In the Lightning Network (LN) channel, this will allow Alice to claim all channel funds if Bob provides an outdated backup, reducing the risk of Bob cheating on Alice and stealing her balance. The proposal sparked a heated discussion. Peter Todd points out its versatility outside of the Lightning Network and proposes a simpler mechanism that doesn't require fraud proofs, while Ghost43 highlights the importance of such proofs when dealing with anonymous peers.
LND adds experimental support for "simple taproot channels", allowing LN funding and commitment transactions to use P2TR to support musig2-style scriptless multisig signatures when both parties are working together. This reduces transaction weight and improves privacy when channel collaboration is closed. LNDs continue to use HTLC exclusively, allowing payments starting from the primary root channel to continue to be forwarded through other LN nodes that do not support the primary root channel.
September
In September, Tom Briar published a draft specification and implementation for compressing Bitcoin transactions. The proposal solves the challenge of compressing evenly distributed data in Bitcoin transactions by replacing integer representations with variable-length integers, using block height and position to reference transactions instead of their output point, txid, and omitting public keys in P2WPKH transactions. While the compressed format saves space, it requires more CPU, memory, and I/O to convert it back to a usable format than it would do with regular serialized transactions, which is an acceptable compromise in situations such as satellite broadcasting or steganography transmission.
2023 Summary Major releases of popular infrastructure projects
● Eclair 0.8.0 adds support for zero-configuration channels and short channel identifier (SCID) aliases.
● HWI 2.2.0 adds support for P2TR key spending using BitBox02 hardware signing devices.
● Core Lightning 23.02 adds experimental support for peer-to-peer storage of backup data and updates experimental support for dual funding and quotes.
● Rust Bitcoin 0.30.0 provides a large number of API changes while announcing a new website.
● LND v0.16.0-beta provides a new major version of this popular LND implementation.
● Libsecp256k1 0.3.1 fixes a code-related issue that should run at a constant time, but doesn't run when compiled in Clang version 14 or later.
● LDK 0.0.115 includes additional support for the experimental delivery protocol and improved security and privacy.
● Core Lightning 23.05 includes support for blind payments, version 2 PSBT, and more flexible affiliate management.
● Bitcoin Core 25.0 adds a new scanblocks RPC that simplifies the use of Bitcoin -cli, adds mini-script support for finalizepsbt RPC, reduces default memory usage with blocksonly configuration options, and speeds up wallet rescans when the compact block filter is enabled.
● Eclair v0.9.0 is a release that "contains a number of important (and complex) lightning features: dual funding, splicing, and BOLT12 provides".
● HWI 2.3.0 adds support for DIY Jade devices, as well as binaries for running the main HWI program on Apple Silicon hardware on MacOS 12.0+.
● LDK 0.0.116 includes support for anchor output and multipath payments with keysend.
● BTCPay server 1.11. X includes improvements to invoice reporting, additional upgrades to the checkout process, and new features for point-of-sale terminals.
● BDK 0.28.1 adds templates for using BIP86 derived paths in descriptors.
● Core Lightning 23.08 includes the ability to change configuration settings for multiple nodes without rebooting the node, support for seed backup and recovery in codex32 format, a new experimental plugin for improved payment pathfinding, experimental support for splicing, and the ability to pay for locally generated invoices.
● Libsecp256k1 0.4.0 adds a module that implements ElligatorSwift encoding, which was later used for the v2 P2P transport protocol.
● LND v0.17.0-beta includes experimental support for "Simple Straight Channels", allowing the use of unannounced channels on-chain using P2TR outputs. This is the first step in adding additional features to LND's pipeline, such as support for Taproot Assets and PTLCs. This release also offers significant performance improvements for Neutrino backend users, with the use of compact block filters and improved LND's built-in watchtower functionality.
● LDK 0.0.117 contains security bug fixes related to the anchor output feature, included in previous releases. The release also includes improved pathfinding, improved watchtower support, and enables bulk financing for new channels.
● LDK 0.0.118 includes some experimental support for the offers protocol.
● Core Lightning 23.11 provides additional flexibility for rune authentication mechanisms, improved backup validation, and new features for plugins.
● Bitcoin Core 26.0 includes experimental support for the version 2 transport protocol, support for taproot, a new RPC for handling assumeUTXO state, and an experimental RPC for submitting transaction packages to the local node's mempool.
October
Gijs van Dam published the results and codes of the study on Payment Split and Switching (PSS). His code allows nodes to divide the received payment into multiple parts that can take different routes before reaching the final recipient. For example, a payment from Alice to Bob can be routed partially through Carol. This technique greatly hinders balance discovery attacks, in which attackers track payments across the network by probing channel balances. Van Dam's study shows that attackers get 62% less information using PSS. In addition, PSS provides higher LN throughput, which may help mitigate channel interference attacks.
Developer ZmnSCPxj has come up with a concept called Side Pool, which aims to enhance liquidity management on the Lightning Network. Sidepools involve multiple forwarding nodes that deposit funds into multi-party off-chain state contracts similar to Lightning Network channels. This allows funds to be redistributed among off-chain participants. For example, if Alice, Bob, and Carol each have 1 BTC, then the status can be updated so that Alice has 2 BTC, Bob has 0 BTC, and Carol has 1 BTC. Participants will still use and advertise regular Lightning Network channels, which can be rebalanced through off-chain peer-to-peer swaps within the state contract if they become unbalanced. This approach is private to participants, requires less on-chain space, and may eliminate off-chain rebalancing fees, increasing the revenue potential of forwarding nodes and the reliability of Lightning Network payments. However, it requires a multi-party state contract, which is not tested in production. ZmnSCPxj proposes to establish LN-Symmetry or duplex payment channels, both of which have advantages and disadvantages.
In October, we completed the first phase of the assumeUTXO project, which contained all the remaining changes needed to use the assumedvalid snapshot chain state and perform a full validation sync in the background. It makes UTXO snapshots available for RPC loading. While this feature set is not yet available to inexperienced users, this merger marks the culmination of a multi-year effort. Proposed in 2018 and formalized in 2019, the project will significantly improve the user experience of new full nodes entering the network for the first time.
The Bitcoin Core project also completed support for version 2 of encrypted P2P transfers specified in BIP324 in October. This feature is currently disabled by default, but can be enabled using the -v2transport option. Encrypted transmissions help improve the privacy of Bitcoin users, preventing passive observers, such as ISPs, from directly determining which transaction nodes are forwarded to their peers. You can also use encrypted transport to detect active man-in-the-middle observers by comparing session identifiers. In the future, additional features may be added that may make it easier for lightweight clients to securely connect to trusted nodes over P2P encrypted connections.
Over the past year, Bitcoin Core has seen some additional improvements to its support for mini-script descriptors. We saw the ability to create small script descriptors for P2WSH output scripts in February. In October, we updated our support for small scripts to support taproot, including tapscript small script descriptors.
Robin Linus and Lucas George described a Bitcoin state compression method using zero-knowledge validity proofs in May. This drastically reduces the amount of state that clients need to download in order to trustlessly verify future operations in the system, for example, by launching a new full node with only a relatively small validity proof, rather than verifying every confirmed transaction on the blockchain. Last October, Robin Linus launched BitVM, a method that can pay bitcoin based on the successful execution of arbitrary programs, without the need for bitcoin's consensus change. BitVM requires a large amount of offline data exchange, but only requires a single on-chain transaction to reach an agreement, or a small number of on-chain transactions if there is a dispute. Even in adversarial situations, BitVM can implement complex trustless contracts, which has caught the attention of some developers.
November
With the final specification of blind paths and onion messages, and their implementation in several popular LN nodes, significant progress has been made this year in the development of offer protocols that rely on them. The offer allows the recipient's wallet to generate a short offer that can be shared with the consumer's wallet. The payer's wallet can use the offer to contact the receiver's wallet via the Lightning Network protocol to request a specific invoice, which can then be paid in the usual way. This allows the creation of reusable offers, each of which can generate a different invoice, which can be updated with current information (e.g. exchange rate) a few seconds before payment, and multiple payments for offers (e.g. subscriptions) can be made through the same wallet, among other features. The existing experimental implementations of quotes in Core Lightning and Eclair were updated over the course of the year and support for quotes was added to the LDK. In addition, the creation of an updated version of the lightning address compatible with the offer was discussed in November.
November also saw an update to the Liquidity Advertising specification, allowing nodes to announce their willingness to contribute a portion of their funds to a new dual-funding channel in exchange for fees, allowing requesting nodes to quickly start receiving incoming Lightning Network payments. Most of these updates are minor, although discussions about whether channels created from liquidity ads should include time-locks continue into December. Timelocks can give buyers an incentive-based assurance that they will actually receive the liquidity they paid for, but timelocks can also be used by malicious or inconsiderate buyers to lock up excess capital in providers.
2023 Summary Bitcoin Optech Summary
In Optech's sixth year, we've published 51 weekly newsletters, published a 10-part series on mempool policy, and added 15 new pages to our subject index. In total, Optech has published more than 86,000 words about the development of the Bitcoin software this year, roughly equivalent to a 250-page book.
In addition, each newsletter this year was accompanied by a podcast, totaling more than 50 hours of audio and 450,000 words of transcript. Many of Bitcoin's top contributors have been guests on the show, and some of them have participated in more than one episode of the show, with a total of 62 different unique guests in 2023:
Optech also released two live reports from the business community: one from BitGo's Brandon Black on implementing MuSig2 to reduce expense costs and improve privacy, and another from Wizardsardine's Antoine Poinsot on building software with miniscript.
December
Some Bitcoin Core developers are beginning to work on a new cluster mempool design to simplify mempool operations while maintaining the necessary order of transactions, where the parent transaction must be confirmed before its child transactions. Transactions are grouped into clusters and then split into blocks sorted by rate, ensuring that blocks with higher rates are confirmed first. This allows for the creation of a block template by simply selecting the highest union block in the mempool, and the deletion of transactions by removing the lowest union block. This fixes some of the existing bad behaviors (e.g., miners may lose fee revenue due to suboptimal evictions) and may be able to improve other aspects of mempool management and transaction relay in the future. The dossier of their discussion was published in early December.
December also publicly announced a new tool for launching a large number of Bitcoin nodes and establishing a defined set of connections between them (usually on a test network). This can be used to test behaviors that are difficult to replicate with a small number of nodes, or that cause problems on public networks, such as known attacks and the spread of gossip information. A public example of using the tool is measuring Bitcoin Core's memory consumption before and after proposed changes.
We thank all of the Bitcoin contributors mentioned above, as well as many others who have done equally important work, for another incredible year of Bitcoin growth. Optech Newsletter will resume its regular Wednesday publication schedule on Jan. 3.