Unsure what you mean by "remixing".
If you're referring to the need to batch swap vtxos because of the expiration, then yes. Especially because you said you have a server?
Discussion
Yes I mean this requirement to deal with expiration of vtxos.
I have a server, but I don't want to trust it, I want it to help me keep my vtxos safe if I didn't open my phone for long time (actually happens, I haven't opened Pheonix for ages and forgot battery mode on for weeks), but I don't want the server to be able to steal, or more importantly I don't want to run a server for others that is legally a custodian of money.
there are different flavors of ark that use CTV and CSFS to reduce the interactivity for the user
https://delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602
for me this is a critical requirement. ark is gimped without at least CTV
This whole spectacle that Ark is "gimped" without a covenant is way over the top.
Yes, Ark can be better with covenants. In fact, at nostr:npub1hf5sgehj874r3y2hps9r36qap20cffauc7t895var2ajlsg32mcqa7dp8n we have both variants developed and concluded that a covenantless variant today is not only viable, but can exceed expectations through the right optimizations and engineering. We have a path for multiple hundreds of vtxo creation in a single commitment transaction while keeping the interactivity at an acceptable level.
We also have paths of varying methods to mitigate the approaching expiry dilemma.
Ark does not need covenants. It is FUD to state otherwise. You'll see soon enough though!
When you say multiple hundreds, let's say 600 transactions per tx, is that on average per 10m (per block), i.e. 1 tx/s?
Are there other upper bounds (or isn't this one?)?
No, this doesn't refer to the typical tps measurement used by blockchains.
I refer to the pragmatic upper bound for creation of new vtxos within a single onchain tx.
This bound is mostly defined by interactivity rounds between participants to construct the covenant. Since we do not have introspection covenants, we use a a series of n-of-n musig transactions. More vtxos = more interactivity.
We've had a functional ark for bitcoin for almost a year now, and since then we've optimized heavily along with plans to go even further. We have methods to achieve the above in concurrency, so that even with a single onchain transaction, we can create higher vtxo counts, without increasing interactivity for each VTXO owner.
In terms of "tps", I would say it is similar to lightning in that we have offchain instant transactions, but with actual transaction composability -- just craft a bitcoin transaction, sign, and submit.
There is of course no free lunch: one must swap their existing vtxos for new ones that are created with the commitment transaction (covenant session) described above, a trustless swap through connector outputs, for two reasons:
Batch expiries: these covenants have an expiry that allow the ark operator to reclaim its initial liquidity.
Switching from preconfirmation security (previous owner + ark operator collusion risk) to bitcoin finality (fully under your control). This also prunes the unilateral exit to a minimum tx set for broadcasting to.covnert vtxos to utxos.
We will release something exactly as you described very soon!
If you don’t extend your contract with the operator technically it’s not your money anymore, it’s theirs.
They may decide to give it back to you but they are not a custodian.
If by "technically" you mean according to consensus rules, I hope you realise not a soul cares about that, not users and not regulators.
Just because people send sats to custodial LN providers addresses, doesn't make that a donation.
You designed this contract (I presume because that is the best you can do with Bitcoin smart contract), but you didn't design it to enable time bomb donations to operators... that is bug not a feature.
Unless of course you do advertise Ark as a time bomb donation to operators, then good luck with adoption and actually good luck with regulators still.
No. The contract involves the operator funding an output onchain for you. You are responsible for rolling your claim over to another batch. If you fail to do so, the operator will sweep the output at termination of the contract as originally specified. The operator keeps no account of its users unlike custodial services.
Ok it is nuanced I will grant you that, but I think our goal is that users can receive bitcoins without any more of a ceremony than having an address, and that money remains passively safe somehow, even if by employing a watchtower, as long as this watchtower can't steal (only fail).
This is the least people expect from payment systems.
However, operational/maintenance fees are acceptable, but losing all the funds wholesale on a such short timeout is just not going to fly.
My baseline is Phoenix LN wallet where presumably the worst that could happen is they close the channel and I pay high fees, or they try to steal and a non custodial watchtower can bail me out.
If Ark is a step forward (no need for opening channels) I hope there are no steps backwards on the other end.
Operators run a business, it would be ill advised for them to run away with user funds even if users leave their outputs to expire. Of course there are plenty of mitigations for this but it's not a dealbreaker.
Cashu mints run a business too, but reputation usually begets KYC, and dark markets beget rug pulls.
The best argument I read so far is that some ASPs could offer longer expiration periods with higher transaction fees, and users can use that for long term savings.