I like Ark, but it has three characteristics that I don't like:

1. The server regularly creates and funds new ark multisigs, and must pass the cost of doing so onto users

2. Users regularly "refresh" their coins by exiting an expiring ark multisig and boarding into a new one, and they bear the cost of doing so plus the annoyance of needing to get online regularly to do it in an interactive group signing session

3. Users pay one another in "out of round" payments that are free to initiate but cost money to settle, which encourages users to keep the funds unsettled, which effectively transforms Ark into a statechain model

The two teams (x.com/ArkLabsHQ and x.com/2ndbtc) have spent a lot of time and money making these characteristics work and optimizing their software so that those pain points are as painless as possible. But my coinpool software eliminates all of those characteristics, so if they switched now, they'd have to throw away a lot of their work.

Still, I recommend they do. I think my model is better and I hope they take a closer look.

https://youtu.be/o-e9IrDrvuo

Reply to this note

Please Login to reply.

Discussion

Someone on twitter asked, "What downsides does it have compared to Ark?"

Here is my answer.

There are three things people have objected to:

(1) Inbound payments require inbound capacity, similar to Lightning. I believe @bergealex4 thinks this is reason enough to dismiss my software as completely unusable, and even ridiculous to compare it with Ark. But I don't think so.

Inbound capacity mostly sucks on Lightning because it causes payment failures when you don't have enough. But coinpool payments are asynchronous: if you don't have enough inbound capacity, the payment doesn't fail, it just stays pending until you get more. And your wallet can even automatically get more inbound capacity for you by just registering to be in another coinpool and deducting a liquidity fee from the inbound payment itself.

I think that compares favorably with Ark; its similar to receiving an out-of-round payment in Ark and then waiting for the next round to settle it. Both require waiting and paying a fee. But a difference is, an out-of-round Ark payment can still be spent even before you settle it, but a pending coinpool payment cannot.

So Ark has an advantage on this particular metric: Ark out-of-round payments are more useful than pending payments on Coinpool because you can start using out-of-round payments immediately. But I don't think this one advantage outweighs the other advantages I spoke of in favor of my software.

(2) You have to do an interactive group signing ceremony to get into a coinpool with my software, and if you use this method to increase your inbound capacity, you have to do it whenever you need more inbound capacity too. But I think this is an "advantage" compared to Ark because Ark *also* requires an interactive group signing ceremony during onboarding, and it *additionally* requires one whenever you want to settle an out-of-round payment *and* whenever your vtxos are about to expire. The more signing ceremonies required, the worse the software, imo, and while my software requires it sometimes, I think Ark requires it far more.

(3) In the failure case where the server completely disappears, my software is less efficient than Ark in terms of the number of transactions required to get everyone out. In Ark, their tree-method scales quadratically, meaning if you have 100 users, they can all get out in no more than 10 transactions apiece, and most of these transactions are "shared" by several users, so some users (the poorest) might get lucky and only have to broadcast 1 transaction.

Whereas my exit ladder method only scales linearly: each user must broadcast 4 transactions, so with 100 users, that's 400 transactions in total. However, I think there's another side to this story: in an Ark with 100 people, each user must store all of the 10 txs necessary to exit, and be prepared to broadcast and pay for them, because there is no guarantee that anyone "higher" than them in the tree will do it for them. So even poor people might have to broadcast 10 txs to exit Ark, and must be prepared to do so, even though they will *probably* only have to pay for a few of them.

Whereas in my software each user always has to broadcast precisely 4 or 5 transactions to exit unilaterally, unless you put more than 100 people in the same pool. I think it's worth a lot to have an exact, static number of txs to thunk about, and I'm not sure if that's better or worse than Ark.

So in summary, the disadvantages of Coinpool are:

- in Coinpool, if you dont have enough inbound capacity, you can't start spending your pending payments immediately, whereas the equivalent type of payment in Ark is *always* spendable immediately

- you might have to do an interactive signing ceremony for a thing tha Ark doesn't need one for (inbound capacity), but I still think Coinpool wins on this front by eliminating them in most of the other cases where Ark needs them

- Ark has more efficient unilateral exits "in total," and, in many cases (e.g. for most poor users), "per user" as well, but Coinpool requires an exact, small number of exit transactions per user, and I'm not sure which model is better on this metric.

And in terms of Coinpool advantages:

- The server does not need to regularly create and fund new multisigs because Coinpool multisigs last indefinitely, they mostly don't expire unless everyone leaves that pool. This means fewer costs for the server, and thus fewer costs for users.

- Users do not need to do a signing ceremony to settle their inbound payments, except in the case where they have insufficient inbound capacity. Since these ceremonies, in Ark *and* Coinpool, require users to wait for them to happen and then pay a fee, it is good to reduce them, which Coinpool does.

- Coinpool users do not need to "refresh" their coins on a regular basis. This costs money and time for the same reasons given in the point above, it's another signing ceremony and it's annoying. By almost entirely eliminating it, Coinpool is superior in this respect.

(For the dimwits in the back of the room like me) : do we need a consensus change for coinpools or is it usable right now?

Coinpools don't need a consensus change. They are usable right now, if a good coder writes the code. (My proof of concept code is only "usable" in a very loose sense of the term, because I am not a good coder.)

Wonderful! Thank you!!