Skip to content

Developing news

Jump to bottom
David A. Harding edited this page Mar 30, 2025 · 19 revisions

This page contains a list of news stories from our sources that we plan to summarize for a future newsletter. For regular News items, we try to summarize all significant discussion from the previous week (Monday-Sunday), but sometimes a story is borderline notable and could use some seasoning, or it's too complicated for us to figure out quickly (possibly leading us to schedule a Deep Dive), or our writers simply don't have enough time to work on it this week. On rare occasion, we might also delay writing about something for our Notable Code and Documentation Changes section, usually because we need to do additional research to understand it. We also won't write about anything that best fits into one of our monthly sections (e.g. Changing Consensus or Changes to Services and Client Software) until that section is next published, unless the news is especially urgent.

Any Optech contributor is welcome to add to this list (please be sure to include at least one link per item). Items will be removed when they are written about or when it's clear that we won't write about them. Note that many stories which initially make this list will not be written about: when we take a serious look at them, they turn out to be less interesting than anticipated.

News

Changing Consensus

Clipboard

  • How CTV could benefit Ark users: Steven Roose [posted][] to Delving Bitcoin a short description of the currently deployed [Ark][] protocol, called coventless Ark (clArk), and how the availability of the [OP_CHECKTEMPLATEVERIFY][] (CTV) opcode could make a [covenant][topic covenant]-using version of the protocol more appealing to users.

    One design goal for Ark is to allow [async payments][]: payments made when the receiver is offline. In clArk, this is achieved by the spender plus an Ark server extending the spender's existing chain of presigned transactions, allowing the receiver to ultimately accept exclusive control over the funds. The payment is called an Ark out-of-round payment (arkoor). When the receiver comes online, they can choose what they want to do:

    • Exit: broadcast the entire chain of presigned transactions, exiting the [joinpool][] (called an Ark). When the presigned transactions are confirmed to a suitable depth, the receiver can be certain they have trustless control over the funds. However, they lose the benefits of being part of a joinpool, such as rapid settlement and lower fees deriving from UTXO sharing. They may also need to pay transaction fees to confirm the chain of transactions.

    • Nothing: in the normal case, a presigned transaction in the chain of transactions will eventually expire and allow the server to claim the funds. This is not theft---it's an expected part of the protocol---and the server may choose to return some or all of the claimed funds to the user in some way. Until the expiry approaches, the receiver can just wait.

      In the pathological case, the server and spender can (at any time) collude to sign an alternative chain of transactions to steal the funds sent to the receiver. Note: Bitcoin's privacy properties allow both the server and the sender to be the same person, so collusion might not even be required. However, if the receiver keeps a copy of the chain of transactions cosigned by the server, they can prove that the server stole funds, which might be sufficient to deter other people from using that server.

    • Refresh: with server cooperation, atomically transfer ownership over the funds in the spender-cosigned transaction for another presigned transaction with the receiver as cosigner. This extends the expiration date and eliminates the ability for the server and previous sender to collude to steal the previously sent funds. However, refreshing requires the server hold on to the refreshed funds until they expire, reducing the server's liquidity, so it charges the receiver an interest rate until expiration (paid upfront since the expiration time is fixed).

    Another design goal for Ark is to allow participants to receive LN payments. In his original post and a [reply][], Roose describes that existing participants who already have funds inside the joinpool can be penalized up to the cost of an onchain transaction if they fail to perform the interactivity required for receiving an LN payment. However, those who don't already have funds in the joinpool can't be penalized, so they can refuse to perform the interactive steps and costlessly create problems for honest participants. This effectively prevents Ark users from receiving LN payments unless they already have a moderate amount of funds on deposit with the Ark server they want to use.

    Roose then describes how the availability of CTV would allow improving the protocol. The main change is how Ark rounds are created. An Ark round consists of a small onchain transaction that commits to a tree of offchain transactions. These are presigned transactions in the case of clArk, requiring all of the spenders in that round be available for signing. If CTV was available, each branch in the tree of transactions can commit to its descendents using CTV with no signing required. This allows the creation of transactions even for participants who aren't available at the time the round is created, with the following benefits:

    • In-round non-interactive payments: instead of Ark out-of-round (arkoor) payments, a spender who is willing to wait for the next round can pay the receiver in-round. For the receiver, this has a major advantage: as soon as the round confirms to a suitable depth (and maybe earlier if they're willing to trust incentives for honest server operation), they receive trustless control over their received funds (until expiration approaches, at which time they can either exit or cheaply refresh).

    • LN receiving to a new account: FIXME:harding unclear to me what the benefit is here, replied at https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528/8

Clone this wiki locally