This special edition of the Optech Newsletter summarizes Bitcoin’s notable developments throughout 2023. This is the continuation of our 2018, 2019, 2020, 2021 and 2022 summaries.
January
Anthony Towns announced Bitcoin Inquisition, a software fork of Bitcoin Core designed to be used for testing default signatures for proposed soft forks and other major protocol changes. By the end of the year, it included support for several proposals: SIGHASH_ANYPREVOUT, OP_CHECKTEMPLATEVERIFY, and basic temporary anchors, with pull requests opened 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 method for opening Lightning Network channels that addresses the challenges faced by wallets on mobile devices that are often offline. Funds can be received in an on-chain transaction while the client is offline. When the client is back online, the transaction can receive enough confirmations to immediately and securely open a channel with a pre-selected peer without any trust in that peer. Within a few months of this proposal, at least one popular Lightning Network wallet used an implementation of this idea.
The standard format for wallet tag export and import was specified with the identifier BIP329. This standard not only makes it easier to back up important wallet data that cannot be restored from a BIP32 seed, but 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 implemented BIP329 outputs.
February
In February, a discussion began that would continue throughout the rest of the year about Ordinals and Inscriptions, two related protocols for associating meaning and data with transaction outputs. Andrew Poelstra summarized the position of many protocol developers: "There is no sensible way to prevent people from storing arbitrary data in witnesses without incentivizing worse behavior and/or undermining legitimate use cases." Given the approach used by Inscriptions that allows for large amounts of data to be stored, Christopher Allen proposed increasing Bitcoin Core's 83-byte limit on data stored in outputs prefixed with OP_RETURN. Later that year, Peter Todd also proposed this.
BitcoinSearch.xyz launched at the beginning of the year as a search engine for Bitcoin technical documentation and discussions. By the end of the year, the site offered a chat interface and summaries of recent discussions.
Core Lightning adds experimental support for peer-to-peer storage backups, allowing a node to store a small encrypted backup file for its peers. If a peer needs to reconnect later, perhaps after losing data, it can request the backup file. The peer can decrypt the file using a key derived from its wallet and use the file contents to restore the latest state of all its channels.
Joost Jager proposed a "high availability" flag for Lightning Network channels, allowing the channel to signal that it provides reliable payment forwarding. Christian Decker pointed out the challenges of creating a reputation system, such as nodes not being encountered frequently. Another approach proposed before was also mentioned: overpayments with recycling (formerly known as boomerangs or refundable overpayments), in which payments are split and sent through multiple routes, reducing the reliance on high-availability channels.
Ideas from a paper published last year have become a particular focus for mitigating Lightning channel interference in 2023. In February, Carla Kirk-Cohen and co-author Clara Shikhelman began soliciting feedback on proposed parameters for implementing one of the ideas in the paper, HTLC endorsements. In April, they released a draft specification for a test plan. In July, the idea and proposal were discussed at a Lightning Network development meeting, which led to some mailing list discussions about an alternative approach where the costs paid by both attackers and honest users reflect the potential costs paid by node operators who provide services, so that if attackers start using these services, node operators who provide services to honest users and receive reasonable rewards will continue to receive reasonable rewards. In August, developers associated with Eclair, Core Lightning, and LND announced that they were all implementing parts of the HTLC endorsement protocol in order to begin collecting data related to it.
Russell O’Connor and Andrew Poelstra proposed a new BIP for backing up and restoring BIP32 mnemonics, called codex32. Similar to SLIP39, it allows multiple shares to be created using the Shamir secret sharing scheme with a configurable threshold requirement. If the attacker obtains fewer shares than the threshold, then he will learn nothing about the mnemonic. Unlike other recovery codes that use wordlists, codex32 uses the same alphabet as bech32 addresses. The main advantage of codex32 over existing schemes is its ability to perform all operations manually using pen, paper, instructions, and paper cuts, including generating the encoded mnemonic (using dice), protecting the mnemonic with a checksum, creating a checksum share, verifying the checksum, and recovering the mnemonic. This allows users to periodically verify the integrity of individual shares without relying on a trusted computing device.
March
In March, anonymous developer John Law published a paper describing a way to create a hierarchy of channels for multiple users transacting on a single chain. The design could allow all online users to spend their funds in the event that some of their channel counterparties are offline, which is currently not possible in the Lightning Network. This optimization would allow always-online users to use their funds more efficiently, potentially reducing costs for other users of the Lightning Network. The proposal depends on Law’s adjustable penalty protocol, which has not seen any public software development since it was proposed in 2022.
Summary of 2023 Soft Fork Proposals
James O’Beirne published a proposal for a new OP_VAULT opcode in January, followed by a draft BIP for a Bitcoin survey implementation in February. A few weeks later, Gregory Sanders proposed an alternative design for OP_VAULT.
The “Make Everything Uniform” (MATT) proposal, first proposed last year, reappeared this year. Salvatore Ingala showed how it could provide much of the functionality of the proposed OP_VAULT opcode. Johan Torås Halseth further demonstrated how an opcode from the MATT proposal replicated key functionality of the OP_CHECKTEMPLATEVERIFY proposed opcode, albeit with a less space-efficient MATT version. Halseth also used the opportunity to introduce readers to a tool he developed, Tapsim, that allows debugging of Bitcoin transactions and Tapscript.
In June, Robin Linus described how users could lock up funds today, use them on a sidechain for a long period of time, and then allow recipients of the funds on the sidechain to efficiently withdraw them to Bitcoin at a later point in time, but only if Bitcoin users eventually decide to change the consensus rules in some way. This could allow users willing to take on financial risk to start using their funds immediately and get the new consensus features they want, while providing a path for those funds to return to Bitcoin's mainnet later.
In August, Brandon Black proposed a version of OP_TXHASH combined with OP_CHECKSIGFROMSTACK that would provide much of the functionality of OP_CHECKTEMPLATEVERIFY (CTV) and SIGHASH_ANYPREVOUT (APO) without adding much on-chain cost over those individual proposals.
In September, John Law proposed using contracts to enhance the scalability of the Lightning Network. He used a structure similar to channel factories and the proposed Ark protocol to potentially fund millions of off-chain channels that could be recovered by factory funders after expiration, with users being able to withdraw funds through 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 forced expiration flood problem, where the failure of a large user could force many time-sensitive on-chain transactions at the same time. Law responded that he was working on a solution to delay expiration during periods of high transaction fees.
At the beginning of October, Steven Roose published a draft of a new OP_TXHASH opcode. The idea of the opcode has been discussed before, but this is the first specification of the idea. In addition to describing exactly how the opcode works, the paper also examines some of the drawbacks, such as the fact that a full node may need to hash up to several megabytes of data each time the opcode is called. The BIP draft includes an example implementation of the opcode.
Also in October, Rusty Russell worked on Universal Contracts, which makes minimal changes to Bitcoin’s scripting language, and Ethan Heilman published a draft BIP that adds an OP_CAT opcode that can concatenate two elements on the stack. Discussions on both topics will continue into November.
Before the end of the year, Johan Torås Halseth also suggested that a covenant-style soft fork could allow multiple HTLCs to be aggregated into a single output, and if one party knew all of the pre-images, they could spend all of the contents at once. If one party only knew some of the images, they could claim only those and return the remaining balance to the other party. This would be more efficient on-chain and could make it more difficult to perform certain types of channel jamming attacks.
April
Sergi Delgado Segura proposed an accountability mechanism for watchtowers that fail to respond to protocol violations that they are able to detect. For example, Alice provides a watchtower with data for detecting and responding to the confirmation of an old Lightning Network channel state. Later, the state is confirmed, but the watchtower does not respond. Alice wants to be able to hold the watchtower operator accountable by publicly proving that it did not respond appropriately. Delgado proposed a mechanism based on cryptographic accumulators that watchtowers can use to create commitments that users can use to generate proofs of liability when violations occur later.
Routing blinds, first described three years ago, were added to the Lightning Network specification in April this year. It allows the receiver to provide the sender with the identifier of a specific forwarding node, and the 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 information for the next hop, which decrypts the hop after it, and so on until the payment reaches the recipient's node and the sender And no forwarding node can (definitely) know which node belongs to the receiver. It significantly improves the privacy of receiving funds using the Lightning Network.
BIP327 was assigned to the MuSig2 protocol in April for creating scriptless multi-signatures. The protocol will be implemented in multiple projects and systems within a year, including LND's Signrpc RPC, Lightning Lab's Loop service, BitGo's multi-signature service, LND's experimental simple taproot channel, and a BIP draft for extending PSBT.
Maxim Orlovsky announced in April the release of RGB v0.10, a new version of the protocol that allows the creation and transfer of tokens (among other things) using contracts defined and verified off-chain. Changes in contract state (such as transfers) are associated with on-chain transactions in a way that uses no additional block space over typical transactions and keeps all information about the state of a contract (including its existence) completely confidential from third parties. Later in the year, the Taproot Asset Protocol, which was derived in part from RGB, released a specification intended to become a BIP.
April also saw significant discussion on the proposed splicing protocol, which allows nodes to continue using a channel while adding or removing funds from it. This is particularly useful for keeping funds in a channel while still allowing instant on-chain payments to be made from that balance, allowing wallet UIs to show users a single balance from which they can make on-chain or off-chain payments. By the end of the year, both Core Lightning and Eclair will support splicing.
May
A set of draft specifications for Lightning Service Providers (LSPs) were 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 part describes an API for setting up and managing just-in-time (JIT) channels.
Dan Gould has spent the better part of a year working on enhancing the Payjoin protocol, a privacy-enhancing technique that makes it more difficult for third parties to reliably link inputs and outputs in a transaction to a payer or receiver. In February, he proposed a serverless payment protocol that can be used even if the receiver is not running an always-on HTTPS server on a public network interface. In May, he discussed several advanced applications for using Payjoin, including various payment passthroughs, where, for example, instead of Alice paying Bob, Alice pays Bob’s supplier (Carol), thereby reducing the debt Bob owes her (or prepaying an expected future bill)—which saves block space and further improves the privacy of standard payment connections. In August, he published a draft BIP for serverless payments that does not require the payer and receiver to be online at the same time (although they each need 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 Payjoins with Bitcoin Core.
Burak Keceli proposed a new federated pool-style protocol called Ark, where Bitcoin owners can choose to use a counterparty as a co-signer on all transactions for a specific time period. The owner can withdraw the Bitcoin on-chain after the timelock expires, or transfer the Bitcoin to the counterparty off-chain immediately before the timelock expires. The protocol provides a trustless single-hop, one-way atomic transfer protocol from the owner to the counterparty for various uses such as mixing coins, making internal transfers, and paying Lightning Network invoices. Compared to the Lightning Network, there have been increased concerns about the high on-chain footprint and the need for operators to keep large amounts of funds 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 released a draft BIP for silent payments, a reusable payment code that generates a unique on-chain address with each use, preventing outgoing links. Outgoing links can significantly reduce the privacy of users, including those not directly involved in the transaction. The draft details the benefits of the proposal, its pros and cons, and how 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 reported three major security breaches this year:
Milk Sad vulnerability in Libbitcoin bx: Lack of entropy in the command to create a wallet was a widely undocumented vulnerability that ultimately led to the theft of large amounts of Bitcoin from multiple wallets.
● Denial of service for fake funds against Lightning Network nodes: Matt Morehouse privately discovered and responsibly disclosed a denial of service attack. All affected nodes were able to update, and at the time of writing we are not aware of the vulnerability being exploited.
● Replacement Cycles Targeting HTLCs: A fund-stealing attack targeting HTLCs used in the Lightning Network and other protocols was privately discovered and responsibly disclosed by Antoine Riard. All Lightning Network implementations tracked by Optech deploy mitigations, though the effectiveness of these mitigations is a subject of discussion and other mitigations have been proposed.
July
The Verified Lightning Signer (VLS) project released its first beta in July. The project allows Lightning Network nodes to be separated from the keys that control their funds. Lightning Network nodes running VLS will route signature requests to remote signing devices instead of local keys. The beta version supports CLN and LDK, first and second layer validation rules, backup and recovery capabilities, and provides a reference implementation.
The Lightning Network developer meeting held in July discussed various topics, including reliable transaction confirmations at the base layer, taproot and MuSig2 channels, updated channel announcements, PTLCs and redundant overpayments, channel interference mitigation proposals, and simplified commitment and specification processes. Other Lightning Network discussions at the same time included cleaning up the Lightning Network 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 across the network. As with payments, messages are encrypted using onion, so each forwarding node only knows which peer it received the message from and which peer should receive it next. The message payload is also encrypted so only the final recipient can read it. Onion messages use blind paths, which were added to the Lightning Network specification in April, and onion messages themselves are also used by the proposed quote protocol.
Thomas Voegtlin proposed a protocol that allows for penalties for providers who provide outdated backup states to users. The service involves a simple mechanism where user Alice gives a backup of data with a version number and signature to Bob. Bob adds a nonce and submits the full data with a timestamped signature. If Bob provides outdated data, Alice can generate a fraud proof proving that Bob previously signed a higher version number. This mechanism is not Bitcoin-specific, but combined with certain Bitcoin opcodes it can be used on-chain. In a Lightning Network (LN) channel, this would allow Alice to claim all channel funds if Bob provides an outdated backup, reducing the risk that Bob could deceive Alice and steal her balance. The proposal sparked a lively discussion. Peter Todd pointed out its versatility beyond the Lightning Network and proposed a simpler mechanism that does not require fraud proofs, while Ghost43 stressed the importance of such proofs when dealing with anonymous peers.
LND has added experimental support for "simple masterroot channels", allowing Lightning Network funding and commitment transactions to use P2TR to support musiG2-style scriptless multi-signature signing when both parties cooperate. This reduces transaction weight and improves privacy when the channel is closed cooperatively. LND continues to use HTLC exclusively, allowing payments started from the masterroot channel to continue to be forwarded through other Lightning Network nodes that do not support masterroot channels.
September
In September, Tom Briar published a draft specification and implementation for compressing Bitcoin transactions. The proposal addresses the challenge of compressing uniformly distributed data in Bitcoin transactions by replacing integer representations with variable-length integers, using block heights and positions to reference transactions instead of their output point txids, and omitting public keys in P2WPKH transactions. While the compressed format saves space, converting it back to a usable format requires more CPU, memory, and I/O than processing regular serialized transactions, which is an acceptable tradeoff in situations such as satellite broadcasts or steganographic transmissions.
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 the BitBox02 hardware signing device.
Core Lightning 23.02 adds experimental support for peer storage of backup data and updates experimental support for dual funding and quoting.
Rust Bitcoin 0.30.0 comes with a number of API changes, and a new website has been announced.
LND v0.16.0-beta provides a new major version of this popular LND implementation.
Libsecp256k1 0.3.1 fixes an issue related to code that should run in constant time but did not when compiled with Clang version 14 or later.
●LDK 0.0.115 includes more support for experimental provisioning protocols and improves 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, simplifies the use of bitcoin-cli, adds mini-script support to the finalizepsbt RPC, reduces default memory usage via the blocksonly configuration option, and speeds up wallet rescans when the compact blocks filter is enabled.
●Eclair v0.9.0 is a release that “contains preparation work for many important (and complex) lightning features: dual funding, splicing, and BOLT12 provisioning.”
●HWI 2.3.0 adds support for DIY Jade devices, and binaries for running the main HWI program on Apple Silicon hardware with macOS 12.0+.
●LDK 0.0.116 includes support for anchor output and multi-path 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 derivation paths in descriptors.
Core Lightning 23.08 includes the ability to change multiple node configuration settings without restarting the node, support for seed backup and restore in codex32 format, a new experimental plugin for improved payment pathfinding, experimental support for splicing, and the ability to pay locally generated invoices.
Libsecp256k1 0.4.0 added a module that implements ElligatorSwift encoding, which was later used in the v2 P2P transport protocol.
●LND v0.17.0-beta includes experimental support for "Simple Straight Channels", allowing unannounced channels to be used on-chain using P2TR outputs. This is the first step in adding additional features to LND’s channels, such as support for Taproot Assets and PTLCs. This release also provides significant performance improvements for users of the Neutrino backend, uses compact block filters, and improves LND’s built-in watchtower functionality.
LDK 0.0.117 includes security bug fixes related to the anchor export functionality included in the previous version. This version also improves pathfinding, improves watchtower support, and enables batch funding of new channels.
●LDK 0.0.118 includes partial experimental support for the offers protocol.
Core Lightning 23.11 provides additional flexibility to the rune authentication mechanism, improved backup verification, and new features for plugins.
Bitcoin Core 26.0 includes experimental support for version 2 of the transport protocol, support for taproot, a new RPC for handling assumeUTXO state, and an experimental RPC for submitting transaction bundles to the local node’s mempool.
October
Gijs van Dam published research results and code on Payment Splitting and Switching (PSS). His code allows nodes to split received payments into multiple parts that can take different routes before reaching the final recipient. For example, a payment from Alice to Bob can be partially routed through Carol. This technique greatly hinders balance discovery attacks, where attackers track payments across the network by probing channel balances. Van Dam's research shows that attackers gain 62% less information using PSS. Additionally, PSS provides higher Lightning Network throughput, which may help mitigate channel jamming attacks.
Developer ZmnSCPxj has proposed a concept called side pools that aims to enhance liquidity management on the Lightning Network. Side pools involve multiple forwarding nodes depositing funds into a multi-party off-chain state contract similar to a Lightning Network channel. This allows funds to be redistributed between participants off-chain. For example, if Alice, Bob, and Carol each have 1 BTC, the state can be updated so that Alice has 2 BTC, Bob has 0 BTC, and Carol has 1 BTC. Participants would still use and advertise regular Lightning Network channels, and if these become unbalanced, they can be rebalanced through off-chain peer-to-peer swaps within the state contract. This approach is private to participants, requires less on-chain space, and could potentially eliminate off-chain rebalancing fees, thereby increasing the earning potential of forwarding nodes and the reliability of Lightning Network payments. However, it requires a multi-party state contract, which is untested in production. ZmnSCPxj suggests building 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 included all remaining changes needed to snapshot the chain state using assumedvalid and perform a full validation sync in the background. It enables UTXO snapshots to be loaded via RPC. While this feature set isn't yet directly accessible to inexperienced users, the merger marks the culmination of years of work. The project, proposed in 2018 and formalized in 2019, will significantly improve the user experience for new full nodes entering the network for the first time.
The Bitcoin Core project also completed support for version 2 of the encrypted P2P transport specified in BIP324 in October. This feature is currently disabled by default, but can be enabled using the -v2transport option. Encrypted transport helps improve the privacy of Bitcoin users by preventing passive observers (such as ISPs) from directly determining which transactions nodes forward to their peers. Encrypted transport can also be used to detect active man-in-the-middle observers by comparing session identifiers. In the future, other features may be added to 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 mini-script descriptor support. We saw the ability to create mini-script descriptors for P2WSH output scripts in February. In October, we updated our mini-script support to support taproot, including mini-script descriptors for tapscript.
Robin Linus and Lucas George described a method for compressing the Bitcoin state using zero-knowledge validity proofs in May. This significantly reduces the amount of state that clients need to download in order to trustlessly verify future operations in the system, for example, by starting a new full node with only a relatively small validity proof, rather than verifying every confirmed transaction on the blockchain. Last October, Robin Linus introduced BitVM, a method that can pay Bitcoin based on the successful execution of arbitrary programs without requiring consensus changes to Bitcoin. BitVM requires a large amount of off-chain data exchange, but only a single on-chain transaction to reach an agreement, or a small number of on-chain transactions if there is a dispute. BitVM can achieve complex trustless contracts even in adversarial situations, which has attracted the attention of some developers.
November
With the final specifications for Blind Paths and Onion Messages, and their implementation in multiple popular Lightning Network nodes, this year saw significant progress in the development of the Offer protocol that relies on them. Offer allows a recipient’s wallet to generate a short offer that can be shared with a spender’s wallet. The payer’s wallet can use that offer to contact the recipient’s wallet via the Lightning Network protocol, requesting a specific invoice, which it can then pay in the usual way. This allows the creation of reusable offers, each of which can generate a different invoice, invoices that can be updated with current information (such as exchange rates) seconds before payment, and offers (such as subscriptions) that can be paid multiple times by the same wallet, among other features. The existing experimental implementations of Offer in Core Lightning and Eclair were updated during the year, and support for Offer was added to the LDK. Additionally, the creation of an updated version of Lightning addresses that is compatible with Offer was discussed in November.
November also saw an update to the liquidity advertisement spec, allowing nodes to announce their willingness to contribute a portion of their capital to new dual-funded channels in exchange for fees, allowing requesting nodes to quickly begin receiving incoming Lightning Network payments. These updates were mostly minor, though discussions continued into December about whether channels created from liquidity advertisements should include timelocks. Timelocks can give buyers an incentive-based guarantee that they will actually receive the liquidity they paid for, but timelocks can also be used by malicious or inconsiderate buyers to lock up a provider’s excess capital.
2023 Summary Bitcoin Optech Summary
In Optech’s sixth year, we published 51 weekly newsletters, released a 10-part series on mempool policy, and added 15 new pages to our subject index. In total, Optech has published over 86,000 English words about Bitcoin software development this year, roughly equivalent to a 250-page book.
Additionally, each of this year’s newsletters is accompanied by a podcast, totaling over 50 hours of audio format and 450,000 words of transcripts. Many of Bitcoin’s top contributors have been guests on the show, with some appearing on more than one episode, for a total of 62 different unique guests in 2023:
Optech also published two live reports from the business community: one from Brandon Black of BitGo on implementing MuSig2 to reduce fee costs and improve privacy, and another from Antoine Poinsot of Wizardsardine on building software with miniscript.
December
Some Bitcoin Core developers began working on a new clustered mempool design to simplify mempool operations while maintaining the necessary transaction ordering, where a parent transaction must be confirmed before its children. Transactions are grouped into clusters and then split into blocks sorted by fee rate, ensuring that blocks with high fees are confirmed first. This allows block templates to be created by simply selecting the highest joint block in the mempool, and transactions to be removed by removing the lowest joint block. This fixes some existing bad behavior (for example, miners can lose fee income due to suboptimal evictions), and may be able to improve other aspects of mempool management and transaction relay in the future. An archive of their discussion was published in early December.
Also publicly announced in December was 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 using a small number of nodes, or that would cause problems on a public network, such as known attacks and the spread of gossip information. One public example of the use of this tool is measuring the memory consumption of Bitcoin Core before and after a proposed change.
We thank all of the Bitcoin contributors mentioned above, and the many others whose work is equally important, for another incredible year of Bitcoin development. The Optech Newsletter will resume its regular Wednesday publication schedule on January 3rd.