We’ve made arkoor the standard for payments on our Ark implementation. Instead of offering users the option of making either out-of-round (arkoor) or in-round payments, all payments will be arkoor by default, with in-round transactions reserved for refreshing VTXOs only.

We took this decision after our tinkering indicated that an arkoor-first policy helps on multiple fronts:

• Expands device support by reducing the interactivity between wallets and ASP.
• Offline receive enabled on wallets by default.
• Makes the ASP more reliable with less failed rounds.

Moreover, there are no security trade-offs as long as the receiver chooses to “refresh” into an in-round VTXO in the round immediately after receiving a payment. This takes the same amount of time it does to receive an in-round payment directly. 

Don’t worry, you won’t even notice—Ark payments will be swift and your bitcoin will be self-custodial.

Let’s dive into our motivations and how the new policy works in more detail…

A brief recap: In-round vs. arkoor

There are two ways of constructing a transaction (VTXO) on Ark: 

For more details on how each transaction type works, see our docs.

Interactivity hurts reliability and UX

In a successful Ark round, all users and the ASP will together construct various transactions and sign them. Users connect to the ASP to coordinate and aggregate transaction data and signatures.

Reliability issues of in-round payments

Each round has three phases of interaction.

1. Transaction registration (senders): Senders register their transactions. They tell the ASP which VTXOs they want to spend and what VTXOs they want in return.
2. Tree signing (receivers): All receivers sign their branch of the tree.
3. Forfeit signing (senders): All senders sign the forfeit transactions. The forfeit is conditional on the round coming through.

At each phase in the process things can go wrong. An honest client might lose their internet connection and fail to provide the required signature. Or a malicious client could Denial of Service (DoS) attack the round by providing a faulty signature. In either case, the round must be aborted and restarted.

While an ASP can defend against DoS attacks by banning misbehaving clients, it’s still unavoidable that the more users you have using in-round payments to send to one another, the higher the chances of failed rounds occurring.

UX issues of in-round payments

Then there’s the UX issues of in-round payments. Our current line of thought is to perform a round every hour. This means that an Ark user has to wait up to an hour to attempt the payment. And if the receiver isn’t online at the time, the payment will fail and the sender has to wait another hour for a second attempt.

An in-round payment also requires both the sender and receiver to be online throughout the round—a burden for the sender to coordinate.  

A naïve solution: Sender-signed trees

Sender-signed trees were our first attempt to tackle the problem. In this concept, we modified the round-signing ceremony so that senders could perform all the steps without any signatures from the receivers. This eliminated the need for both sides to be online during the round.

Sender-signed trees result in a slight change to the phases of interactions:

• Transaction registration (senders): Unchanged.
• Tree signing (senders): All senders sign the full tree (not just their branch).
• Forfeit signing (senders): Unchanged.

However, this approach resulted in a new problem: the receiver no longer had a signature in the tree, without which, they couldn’t be absolutely certain that nobody could change the tree with their permission.

In practice, we expect trees to become quite large, making it feel relatively safe to assume that at least one out of, say, 100 senders (or the ASP) is acting honestly. However, this assumption can create a false sense of security, as the ASP could launch a Sybil attack on the receiver. A receiver might believe their transaction is secured by hundreds of independent senders when, in fact, all the senders are the ASP in disguise.

We are not aware of a practical defense against such a Sybil attack and we have abandoned the sender-signed tree concept.

A better solution: Pay out-of-round and refresh in-round

Eventually, we realized the solution was much simpler—just make arkoor transactions the default and reserve in-round transactions to “refreshing” balances only:

1. Sender creates an arkoor VTXO.
2. The ASP cosigns the VTXO.
3. The sender delivers the cosigned VTXO to the receiver via ASP or any other channel. 
4. The receiver chooses to refresh the VTXO in-round in the upcoming round (higher cost), or wait until close to expiry to refresh (lower cost). 

In this model, payments are completed instantly and receivers do not need to be online at the moment of payment. The receiver only needs to come online when they want to perform the refresh. 

The model also significantly reduces the amount of interactivity required by Ark participants each round. Instead of our original sender-receiver round process:

• Transaction registration (senders)
• Tree signing (receivers)
• Forfeit signing (senders)

We now get a receiver-only round process:

• Transaction registration (receivers)
• Tree signing (receivers)
• Forfeit signing (receivers)

In any one transaction, only one user needs to be online. It’s kind of like the receiver is sending transactions to themselves to gain additional security. If the receiver is not online, they simply don’t participate in the round. This will drastically decrease the occurrence of connectivity issues causing rounds to be aborted and restarted.

What if the receiver prefers in-round payments?

This all sounds great, but what about user choice? Isn’t there a security trade-off with arkoor? What if the ASP and the sender collude?

In practice, the receiver doesn’t lose any security compared to direct in-round payments. 

If they prefer in-round VTXOs and choose to refresh their arkoor VTXO as soon as possible, they obtain an in-round VTXO in exactly the same amount of time it takes to receive an in-round VTXO direct from the sender. But they enjoy the additional benefit of receiving an earlier assurance of the payment via the arkoor VTXO:

The only trade-off is that the liquidity fees of the in-round transaction must be borne by the receiver instead of the sender. 

How will this change benefit you?

As a sender, you'll be able to “fire and forget” your payments. As a receiver, you'll be in full control of the security model you want to use and can adapt it to your use case.

Some examples:

• Low-value retail: Alice runs a lemonade stand and sells lemonade for 1,000 sats (~$1). Performing a unilateral exit on a single 1,000 sats VTXO is not economically feasible, so Alice chooses to not refresh her arkoor VTXOs immediately after every sale. Instead, at the end of the week, Alice refreshes all her VTXOs into one aggregate VTXO. This VTXO is sufficiently large to perform a unilateral exit (if she ever needs it) so is worth covering the cost of refreshing in-round.
• High-value retail: Bob has a shop that sells computers for 1,000,000 sats each (~$800). Bob only wants to ship a computer once he is absolutely sure the payment is secure. Bob sets his wallet to refresh his VTXOs every morning so that he can ship all pending orders.

Note that in-round transactions come with a real cost because the ASP needs to pay on-chain fees and allocate capital to make them work. In our new arkoor-first model, the receiver is in total control and can adjust costs based on the security model they need. 

What does the future look like?

In light of these changes, we’ll have to update our nomenclature. The distinction of in-round vs. out-of-round payments isn’t useful anymore. From now on we will simply talk about:

• “Payments”: Assumed to occur out-of-round.
• “Refreshes”: Refreshing arkoor and/or in-round VTXOs into new in-round VTXOs.

We’ll also keep looking into ways to reduce interactivity. For example, if we get covenants on bitcoin, we can completely skip the second phase of the round process in which the tree must be co-signed by all users.

The new arkoor-first model makes Ark more reliable, intuitive, and puts users in control of balancing cost and security. We’re working hard to get it in your hands soon!

To keep up with Ark protocol progress, sign up to our newsletter. Monthly, no spam, unsubscribe at any time.