Hi all, this is Burak. Feel free to ask me anything about Ark. Ark is a new privacy-preserving Bitcoin layer-two idea for those unfamiliar. I would love to address all of your questions or concerns you might have. Stupid questions are welcome :)
I'm currently assembling a team of Bitcoin devs and wizards with the goal of building a prototype. We aim for a rollout later this year on inquisition signet or liquid.
On October 9, 2022, Burak from Bitmatrix (a swap tool built on the Liquid Network) created and broadcast a transaction to the main Bitcoin network, spending a UTXO with a Tapscript multisig with a 998-of-999 threshold. This transaction had 998 individual signatures in the witness field, and was almost 0.1 MB in size, and kind of hilariously, reused the exact same public key for every one of the 999 participants in the multisig. This transaction caused a massive disruption for the Lightning Network by exposing a bug in LND and btcd (an alternative client for the Bitcoin network).
How would mempool fare if a large ASP goes under and all vTXOs need to get on-chain? Is there always enough time to start unrolling your tx with/without CTV congestion control?
We plan to use Rubin's congestion control tree idea for vTXO closures. In a disaster case, it could take years to withdraw from the tree, although the four-week locktime is over.
But even with Congestion Control there would still be a time-limit for lots of tx: one per pool tx that has at least one unspent vTXO. They are smaller than unrolling everything, but there are still ~500k 5-second periods in 4 weeks. Or could they be batched in some way?
You saw the LN as being too difficult and complicated for the new user due to necessity of incoming liquidity, failed transaction, etc. Are you confident Ark will be a seamless, simple experience for a new user?
Absolutely. That's what I designed Ark for. Ark brings custodial-grade UX to self-custody.
Ark offloads complexity from end users to service providers. End-users do not need to take care of their channel management/liquidity. Everything is abstracted from the user, yet the user retains self-custody.
The vTXOs that would have been consumed and created by that coinjoin round are not consumed and not created. For the round to fully fail the ASP probably needs to spend the input they were planning to use in that round in another on chain transaction, which then gives the participants certainty that the coinjoin will never happen, and frees them up to spend their vTXOs in another round.
What would happen if the transaction gets stuck in the mempool.
Can the ASP do an RBF on the transaction or would it require all participants in the coin-join to sign the transaction again.
Eventually someone will need to use it as inputs and they're going to have to pay fees using CPFP, I suppose. Until then, Ark txs will be public so all participants in the round will have an incentive to keep it around to broadcast it if needed.
It does allow the ASP to double spend the input coins though as long as the tx is unconfirmed. Supposedly that can be mitigated by using one of the nonce-fixing strategies.
How much liquidity do you expect a typical ASP to have? Perhaps also explain how you plan to lower the requirements (that old VTXOs will be able to get more efficiently redeemed).
ASPs can customize their fee tier configs and vTXO liveness delta preference according to fee market & liquidity conditions.
One must own a large chunk of BTC to run an ASP infra. Otherwise, its better to join an ASP federation.
Although intense capital requirements, overall, Ark uses liquidity as efficiently as Lightning since recipients are always one hop away from the senders, unlike Lightning, where the liquidity must be deployed on every single hop.
There is also room for liquidity optimizations:
#192143
Does a single user's unilateral exit force everyone in their VTXO set (meaning all users of the ASP who made a payment in that 5 second interval) to chain? If so this could be a type of DoS attack. The single attacker pays an onchain fee, now thousands or tens of thousands of people have to also. Maybe miners even profit from this attack? Pay a single fee and send thousands of fees to miners?
This wouldn't be a DDOS attack. Everyone else's vtxo is locked into the sharedUTXO which is being paid to the ASP until the 4 week timeout.
When the remaining members of the shared UTXO come back online at the 4 week mark, the ASP pushes them into the next coinjoin round to create another sharedUTXO with other people who are entering in that round.
Interesting - so the (slightly) larger on chain size is more than compensated for in your mind by the flexibility?
IIUC these two can do everything that APO + CTV can do with just a few "extra" witness bytes in typical usage, and TXHASH+CSFS can also do many things that CTV+APO cannot.
Trustlessness is a binary option, not a spectrum. There is no such thing as 'more trust' or 'less trust'. It's either trustless or not, and Ark falls into the 'trustless' category.
Decentralization, on the other hand, is a spectrum, yes.
Do you see any potential solutions to addressing the liquidity requirements that doesn't include borrowing bitcoin from lenders and raising ASP fees? Something in the design we can do to potentially make available bitcoin from ARK depositors that the ASP could immediately use to fund transfers?
There is room for two main liquidity optimizations.
vTXO delta auto-adjustments
vTXO liveness delta can adjust to liquidity conditions. i.e if we cut the vTXO liveness delta by half (2 weeks), we also cut this liquidity lockup requirement by two, and so on.
A revocation logic
I'm working on a revocation logic where a set of users in a shared utxo give up their ownership of vTXOs by revealing some secret. ASPs can efficiently redeem these funds without affecting the remaining participants before the four-week locktime is over.
Yeah, Tor makes coinjoins super tricky to coordinate. We're considering less privacy-preserving but more efficient alternatives for the transport layer.
1.We'll have PoC around Ark?
Please don't take my word for it, I've been historically wrong with deadlines, but it's fair to expect a prototype later this year.
2.Ark is compatible with Nostr?
Yes, we plan to use Nostr as the transport layer for Ark; for things like out-of-band communications and coinjoin coordination.
3.What's scenario Ark with PayJoin?
TBH, I don't really know what a PayJoin is and how it works.
4.It will have VC influence like LL, Blockstream?
VC influence on the company, yes. VC influence on the protocol, no.
5.Why CTV is important for Ark?
We need CTV (or a similar proposal) to make Ark work non-interactively. Non-interactive as in receiving funds on the go (without being online).
The public key of the intended vTXO is tweaked with a payment commitment that reveals the payment proof when spent. Tweaking details can be found here:
I thought Bitcoin could only scale on the base layer, as Lightning initially seemed to be a flawed design. Over time, I started exploring the Lighting space more closely and realized some of my objections were addressable. Eventually, I dedicated myself to improving Lightning, which evolved into a distinct new layer two protocol.
The people programed that the segwit activate the inscribtion but not acknowledge that the taproot make it more eadir to inscribe it , it is very risky to change the conseus to make some cool stuff π€£
What would happen if an ASP runs out of liquidity? I know I can take my VTXO and redeem it, so not too worried about that side, but realistically what would be an ASP approach to this? it seems like the only choice would be to wait until more funds can be unlocked from the 14 days lockup period, right?
ASPs would proactively manage liquidity - they have visibility into the flow of funds from expiring pool transactions, and would likely pursue lines of bitcoin credit to bridge times of low expiration flow.
The ASP can also manage liquidity fees to discourage users from making high liquidity requirement payments in times like that. For example spending large vTXOs costs more liquidity than spending small, so the ASP may encourage users to consolidate their small vTXOs to make payments at times of low liquidity. Opposite of on-chain bitcoin in that way where ASP fees being high means its time to consolidate, and ASP fees being low means it's time to consume large "costly" vTXOs.
Has the protocol evolved from when you first released the www.arkpill.me/deep-dive page? If so, will that page get updated or should we follow the Github specs for updates? I like a good spec, but I did find the diagrams on the arkpill.me page helpful
What are confirmation times like on Ark? Reading Ruben Somsen's explanation it seems you need one confirmation on-chain for an Ark transfer, but you could trust that the pool provider doesn't double-spend before it's confirmed.
So would it be safe to send someone funds via Ark and for them to accept it before the next block (or several blocks of confirmation), and also be able to continue to spend those funds into even more transactions
There is a new on-chain transaction i.e every five seconds, so yes, Ark constantly demands bitcoin backspace. I consider this approach footprint-minimal as we can fit thousands of transfers in this transfer period.
Since Ark is based on a shared UTXO model, on-chain fees for the shared UTXO are shared among all other participants.
In Ark, is 1 connector used to gain custody of multiple vTXOs? I was a little confused about this because in the whiteboard video it looked like 1 connector was needed for each redemption of a vTXO.
Connectors output is also a tree of connectors. There is a 1:1 mapping from a connector to an anchor. I used one connector in the whiteboard session to keep things simple.
I've always been obsessed with scaling Bitcoin to the entire planet, although realistically thinking in the end, this is probably not what will happen.
I've been seeking the perfect solution to scaling, and changes are high that Ark might be it.
op_ctvsighash_anyprevoutop_catsomething else