Replying to Avatar Rijndael

Here's my understanding of ARK. I hope nostr:npub18aq8s3z9xl87e74twfk93mljxq6alv4a79yheadx33t9np4g2wkqrtmask can correct me where I mess things up or miss something important :)

Lets ignore getting money into and out of the system for a minute and just talk about what happens once you have money in the system.

In ark, you have a a virtual utxo or a VTXO. The core operation you do is sending a vtxo to someone else

Every 5 seconds the ASP does a coinjoin round. The way you send someone a vtxo is through the coinjoin: you provide an input, they get an output. This happens every 5 seconds so that a mobile user can take out their phone, hit "send" and be done with it. Because coinjoins involve multiple interactive steps for input registration, output registration, and signing, the ASP does them very freqently so that end users dont have to sit there with their phone open for minutes at a time.

At the Ark-layer, the abstraction is that I just send you a vtxo via this coinjoin. Now you have a vtxo and you can hold it, spend it, etc.

What happens at the bitcoin layer is that the ASP created an L1 bitcoin transaction that has one (or more) input and three outputs. The input(s) are provided by the ASP. The outputs are: one for the ASPs change, a "connector output", and a vtxo commitment. the connector output and the vtxo commitment are both CTV commitments to many outputs.

So when I send you vtxos, what that actually means is that in the vtxo-commitment output for that particular coinjoin transaction, there is a spend-path that would let you get your money out onchain after 24 hours (more on this later). This is the unilateral exit path. If I send you money, and you want out of ark, you can reveal a transaction committed to in the vtxo commitment output, and get an onchain payment.

Now, not everyone will want to take onchain payment. Most people will want to take their VTXO and use it in a future pool (coinjoin) transaction to send it to someone else or to self-send it. So, the way that works is when you want to spend your VTXO, you and the ASP sign a 2/2 key path that sends that VTXO to the recipient (via their new VTXO). That transaction also includes an output from the new pools connector commitment. This make the whole thing atomic in a dispute-resolution.

So you have a ton of users who all have VTXOs committed in these outputs. Most want to spend them in ARK. So what happens is the vtxocommitment output can be redeemed onchain by the recipient whenever, can be refunded after two weeks, and can be swept by the ASP after 4 weeks. The idea being that after everyone who is going to claim their onchain funds does, the ASP can sweep that output and use it to fund a new coinjoin/pool round (remember the ASP provides all the inputs, so eventually those inputs should be coming from old pool rounds).

That means that users will need to self-send or move funds every four weeks by creating new vtxos. not a huge deal, but something to build into wallets.

What happens if a user tries to double-spend? well, on the unilateral redeem path, the idea is that if the user has previously signed away that vtxo, then the ASP could reveal that transaction onchain before the user is able to collect their funds.

Because these coinjoins happen every 5 seconds, payment is fast and easy and non-interactive for the receiver. and that coinjoin/pool transaction should end up in the next block. So there is some temporary mempool-doublespend risk where the ASP could double-spend a vtxo between when a payment was sent and when it ends up in a block. You can mitigate that risk by usinga vtxo to pay an LN invoice or something, or just treat it as an unconfirmed transaction and wait for a block.

Overall it's a really interesting design. There are high liquidity requirements (the ASP has to provide onchain liquidity for all the transactions happening in a 4 week perioid until they can sweep old vtxo commitments) and there's the onchain footprint of a 1+ input, 3 output tx every 5 seconds. So we won't have a TON of these, but I think they could be a really interesting way to scale end-user wallets. a hypthetical future might be that end-users use fedimint/cashu type wallets or Ark wallets and then the clearing between ASPs and mints is over lightning.

I think I hit the high-level points. Tell me what I got wrong. Thanks!

Can I ask a million stupid questions?

- what's the connector output?

- why is it a CTV commitment?

- when I send you the vtxo, the ASP updates the vtxo commitment Output such that you can withdraw it?

- what does sending vtxos do with the connector output?

- why does this make the thing atomic and what does it do for dispute resolution (sorry I didn't get that part)

- sending means I do a 2/2 sig with the asp to update the vtxo commitment so it's now yours?

- if I self-send the vtxo to myself every 5 seconds do I DoS the ASP with liquidity requirements?

- double spending: if I double spent a vtxo I've already sent you, by unilaterally exiting, how does the asp prevent that? The asp can sweep my unilateral exit using my vtxo tx that I later did? Do I get punished? Who gets the swept funds?

- if I understand correctly, every pool round must be mined in a block, correct? You can't skip a round, right?

Reply to this note

Please Login to reply.

Discussion

Let's just join Bitcoin Optech Twitter spaces and ask him in a live format

https://twitter.com/i/spaces/1OyJAVeLqraxb

In case these answers are published somewhere by now, is there a link?

I suppose Ark only makes sense if literally hundreds of millions users send txs all the time. Then it justifies spamming UTXO updates in *every* block. Otherwise this on-chain footprint is ridiculous. LN defeats it easily while being faster and less chain-polluting. Also, I don't think Ark would be more effective in case of mass exodus (same as multiple LN channels dying at the same time).

The difference, if I understand it right, is that ASP can simply rob the user if they don't refresh their VTXO without additional on-chain txs and in LN the other peer has to publish a tx (or wait). It's also said in another explanation ( https://github.com/fiksn/awesome-ark/blob/master/explained.md#tradeoff ) that there would be no more than 256 ASPs in total due to on-chain limitations and their capitalization requirements are also pretty high ( https://gist.github.com/RubenSomsen/a394beb1dea9e47e981216768e007454#payment-pool-comparison ), I wonder if those requirements might exceed the total 21M limit. Because the total liquidity is the volume speed (BTC/second) multiplied by the lock time (1 month), so if all BTC are locked in one ASP it'd be limited by ≈8 BTC/sec throughput. Which is already unrealistic if you count the lost coins and those in cold storage.

And who's gonna pay the on-chain fees? How to calculate them? What happens if ASP's UTXO is evicted from mempool or significantly delayed? Or reorganized? Overall, I'm absolutely not sold on this idea, it's kinda fresh and interesting but I don't see how it's practical today. And if it only works for many more users then it doesn't scale well with the capital required.

Or maybe I just don't understand it well enough.