pull down to refresh
but what's the argument against bark and arkade?
The issue is that they run on centralized servers, consequently they are the only party able to coordinate exits. Plus the code is not fully FOSS.
But now that there's a open SSP things may change soon.
If I may, the centralized server isn't what makes something custodial. Before ark there wasn't really a way to spend bitcoin in co-operation with a central server without the server being the custodian. That's the problem which ark solves. There are tradeoffs, 100%, I would never deny that but the centralized server is one potential option for scaling solutions. I don't see a future in which every bitcoiner with a spending wallet is using ark, nor do I see one ark server being the only sheriff in town.
Ultimately the reason I see ark as self-custody is because your coins all have a direct route onchain through presigned multi-sig transactions. It's not like Liquid where you are holding the keys to L-BTC but the underlying value is tied up in a potentially hackable contract. There are asterisks but without sounding too wanky it's a bit of a new paradigm, like how "trust-minimized" became a thing.
I agree with a lot of what you say regarding the language being diluted to fit marketing, it's been rampant in recent years and bitcoiners need to take a stronger stance on what terms mean. Obviously it's harder for me to engage in that debate now that I work on bark but I'll still give my 2 cents.
I'm not criticizing centrality or custody, just centralization. Could a model similar to CASHU, where the user chooses the ASP, be an option in the future?
I know there are not many ASP atm, just wondering if it is something you have in the roadmap or is it just not possible by design?
I'm not criticizing centrality or custody, just centralization. Could a model similar to CASHU, where the user chooses the ASP, be an option in the future?
I know there are not many ASP atm, just wondering if it is something you have in the roadmap or is it just not possible by design?
Bark already supports using a different server, it's just nobody runs one. Maybe one day there will be. There's not much incentive for us to push people to run a competing server since we are trying to build a business however the code is open source. If someone can fund the liquidity then they can run a server
You can also choose between Bark, Wavelength, and Arkade. If these three are successful, more people will run ASPs and more options will be available.
Would have responded sooner but I was driving my kids home. I appreciate your viewpoint here and it is helpful. Also, I use Noah and really like it!
here is one of the things I'm struggling to understand about the trade-offs with Ark:
With lightning I can open a channel to anyone who will have me, whereas with Ark my choice is limited to which Ark I want to join. Once in an Ark, paying others in the same Ark works great, but I'm less convinced about paying out of the Ark via lightning.
It is my understanding of the way gateways in Ark work that an Ark user cannot force a gateway to make a payment. So if the gateways in my particular Ark refuse to let me send out, my recourse is go back to the chain. That's fine, but it seems to me to be a step down from the "trustlessness" of Lightning.
I'm happy to make such tradeoffs because I can't stand managing liquidity and dealing with liveness, but when users want to know whether something is custodial or not, this moves the needle a little bit for me.
What do you think?
If a user can run their own lightning node, manage liquidity and the liveness requirements then they should. Ark isn't going to replace that, however for people who don't want to then ark can be quite compelling.
Yes the server can refuse to sign any payments you try to make but that's why storing your VTXOs locally is so important because it allows you to unilaterally exit without anybody's permission. Bark clients store this by default for this very reason. You do still have to contend with the reality that it might not always be economical to exit however that's much less of a problem for the average bitcoiner imo due to refreshes resetting how many transactions are required to exit.
SSP is different from the statechain entity fwiw. the statechain entity (SE) coordinates reassignment of spending keys in spark. this is a federation of three companies and that code is open source.
SSP is an additive service that makes spending arbitrary amounts easier, and facilitates lightning payments, through atomic swaps. i.e. when you use a "spark lightning wallet" all your payments go through the SSP service (i think this is bad). you could use spark w/o the SSP, but the UX would really suck. SSP makes spark more trusted as well because lightspark is the previous owner in every leaf so your trust assumption is lightspark+lightspark run federation to not rug you.
ark relies on a central server, yes. but all user funds are held in a n-of-n multisig where they have full control over spending (your leaf is server+you to spend plus you get the presigned exit to spend the leaf if server goes offline). now, when you receive offline, you must update your balance to get your newly received funds into a new n-of-n multisig... which is really complicated so you have this trust in server until you "update" your balance on bitcoin.
but if you deposit from bitcoin, into the ark, and then just do payments... the server can't rug you per se. trust us always in receiving offline and that intermediary period where your offchain balance isn't yet reflected on bitcoin
note that ark server can't really steal... it must collude with previous owner to double spend you if have not updated your balance on bitcoin by entering new n-of-n multisig
this post doesn't present any argument as to why spark, arkade, or bark are custodial. spark is custodial in most implementations because you have to call server (1 of 3 nodes) to get your leaf data. agreed.
but what's the argument against bark and arkade?