Grubles and Steven Roose from the Second team here for the next hour or so. We just announced launching Bark (our implementation of Ark) on mainnet.
Happy to discuss anything Ark, Lightning, Bitcoin, covenants, etc.
PS: You can ask grubles about bits too.
Mainnet blog post here: https://blog.second.tech/bark-now-on-bitcoin-mainnet/
It's been great guys! Thank you for the questions. We're signing off for now but will keep checking in for any new questions you guys have.
To get testing on mainnet give this a look: https://second.tech/docs/getting-started/bark-cli/mainnet
If you're looking for some inspiration we also have a page for existing wallets/apps: https://second.tech/docs/built-with-bark
Thanks again!
I've been pretty disappointed with the privacy story for Spark. Can you give me a sense of privacy in bark?
Spark publishes all activity that happens in side their Spark server. We think that is a terrible decision.
Our server doesn't publish any more data than it strictly has to. We only share VTXO-specific information with the owners of the VTXOs.
We run our server similarly to how privacy-aware VPNs run their servers: we keep only the data we have to keep for the protocol to function and try to remove data as soon as we can reasonably do that.
We will obviously have to comply with law enforcement whenever that is relevant, but being proactive in not keeping data we don't need is best we can do there.
Did you get a chance to see @1440000bytes (floppy disk guy)'s post about privacy in Ark?
https://uncensoredtech.substack.com/p/park
We are aware of ways to make the inherent client-server interactions more privacy-preserving. They are hard to build without covenants, so they aren't very relevant currently.
How would covenants make adding privacy to Ark easier?
With covenants it would be possible to make the round protocol more privacy-preserving so that the server cannot link the inputs with the outputs. We came up with a way to do it without covenants as well, but it comes with some extra work required for all users during all rounds, which can add latency to the already fragile interactive process.
It's already possible to do this without covenants. For example, Wasabi's coinjoin coordinators cannot link the inputs with the outputs.
I'm already aware of how you could add privacy to Ark right now without using covenants, my question was "How would covenants make adding privacy to Ark easier?"
Have you looked at burak's new Cube thing?
https://medium.com/cube-bitcoin/introducing-cube-8b3702e470a5
I haven't read it, no. His other new ideas after Ark didn't seem innovative at all.
It seemed pretty complicated to me. Even though I've read through it and spent a bit of time trying to wrap my head around it, I can't say that I could explain it.
zapped from noah using bark
So if i understand correctly, bark works independent from lightning until you need to pay a LN invoice, at which point the payment routes through a bark node.
This feels like a a potential point of failure, trust.
Yes, however this is nothing new and is similar to wallets using an LSP like Phoenix, Blixt, Zeus etc.
To achieve good UX in Bitcoin it looks like you have to make certain tradeoffs.
Aa long as you can unilaterally exit and you're in custody of your money, I think this is workable.
A Lightning payment from a Bark-based wallet is handled trustlessly, the transaction is atomic. If the payment isn't delivered, the Ark balance isn't spent. It uses similar HTLC constructions to pure Lightning transactions. Full details on the trust model here: https://second.tech/docs/learn/payments-lightning
What's the failsafe for spending/receiving bark bitcoin via LN in the event that the bark gateway goes down?
Your wallet can always exit all your VTXOs when the server goes down. That counts for all your VTXOs, whether they are lightning ones or not.
idk what a vtxo is and I couldnt see it on your landing page.
If it's similar to a UTXO, then I would think, in our scenario where your servers go kaput, then sure, I can unilaterally exit, but isn't the risk that these become unspendable on chain?
A vtxo is an off-chain utxo backed by funds that have been escrowed on-chain. There's always a series of presigned transactions that can take you from the on-chain transaction to getting your vtxo published on-chain (effectively turning it into a regular utxo). Your Bark wallet will make sure it has these presigned transactions before it registers any incoming payments so you'll never see funds that you won't be able to unilaterally exit from
Thanks for clarifying. There may still be a part I am missing.
Is this exit mechanism similar to a LN channel close, in the sense that funds get sent to a new address?
Yeah, the unilateral exit can be thought of as working in a somewhat similar way. Exiting can be done by spending the published vtxo to a new address
This is messing with my head. If I am using this and lose my phone and only have my seed phrase, is that sufficient to reconstruct my full balance and the entire VTXO transaction chain from on-chain data alone? Is there per-VTXO state stored on-device (indices, round data, specific tx chains) that I'd also need to have backed up to recover?
Yes. Your wallet's database is necessary for you to access your funds and you should always back it up properly. We're looking into ways to help our integrators do this, but currently it's a single file that they can encrypt and store anywhere.
We are also working as a last-resort recovery with the Ark server. This will obviously only work if the Ark server is being cooperative.
Yes, there's per-vtxo state stored on-device. You need the metadata associated with your vtxos to recover your wallet. One of the threads on Second's forum discusses making a backup format for this if you're interested in reading more:
https://community.second.tech/t/announcing-v-pack-independent-verification-and-visualization-for-the-vtxo-ecosystem/183
Appreciate the answer! I'll check out that forum thread.
How much bitcoin do you need to run an ASP if you ran it the most "budget" way possible? can you configure round times, etc. to lower the barrier to entry so we have more independent ASPs?
The full server is open source and all parameters are configurable. It is possible to keep costs low by hosting rounds infrequently.
The cost of running an Ark server is mainly driven by the onchain fee-rate. Currently, you can get a transaction onchain for a few 20 cents. If you run an Ark server that hosts a round every 24 hours this is something a hobbyist can afford.
I saw bark supports as little as 1 sat send/receive which enables great UX, how did you solve this? (I thought there was an issue with amounts lower than dust)
We do support them, but with a caveat. Dust amounts (< 330 sat) cannot propagate through the bitcoin relay network. So even though it is possible to transact such low amounts inside the Ark, these received funds are not safe if the Ark server disappears because they cannot be redeemed onchain.
However, if you keep receiving them and eventually have amounts larger than 330 sats, your wallet will automatically consolidate your balance into a single VTXO and you will be able to exit.
What’s the difference between bark and an LN custodian?
The biggest and probably most important difference is Bark allows you to unilaterally exit your bitcoin. LN custodians hold your bitcoin for you, so there is no ability for you to exit without their permission.
So you're saying you can't block me from withdrawing? What happens if your servers are down or unreachable? Can I still withdraw my sats?
Yes, we have a unilateral exit.
Your vtxo is just a chain of normal bitcoin transactions.
You can publish them to the blockchain.
You are in control of the coins. Not the server
That’s interesting! Do you have an app where I can try a unilateral exit with direct publishing on the blockchain?
I recommend testing this on signet with the Noah app: https://github.com/smolcars/noah
You can get signet sats from our faucet: https://signet.2nd.dev
Alternatively you can use mainnet, it's well tested but it'll cost you real sats.
thanks
I have multiple questions:
While Spark did have a head start, we see that they are focussing a lot on stablecoin payments and other tokenization things where security trade-offs are inherent to the currency used.
We don't think the Spark model fits the bitcoin ethos particularly well. When you run a Spark-based wallet today, you still get in big trouble if the Spark entity disappears and can get totally rugged if the entity is actively malicious.
Bark is built with the bitcoin ethos as our central guidance. Our client is user-first, with protections against malicious servers built into every interaction. When an Ark server disappears or becomes malicious, Bark users will be fine and have their funds properly exited onchain.
In the end, this is what bitcoiners expect from a bitcoin wallet.
The original Ark protocol was based on CTV, but CTV eventually didn't get adopted by the bitcoin community.
By using CTV, the original designs for Ark had very limited interactivity requirements from the users. Users only had to deal with the server.
Without CTV, we had to replace all covenant usage with what we call pseudo-covenants that are enforced by multisigs with all users that are affected by the policy. This introduces a loooot of interactivity work. Users need to be online at the same time to sign lots of bitcoin transactions.
It forced us to make some trade-offs to make this work for mobile wallets as well.
We're happy with the way it turned out, but we would definitely have been able to launch 6 months earlier if we had CTV :)
Definitely think that our main contributions were in realizing that the original Ark protocol wasn't finished and going back to the drawing table. We came up with several new designs for Ark-like protocols and implemented a (covenant-less) variant of one of them: hArk. We intend to implement Erk or something similar in a covenant future.
We also recognize that the design space for such protocols is still very much open. When trying to implement a specific instance of a protocol, tunnelvision is a real effect. Someone with the capacity to take a step back and go back to the drawing board again, can probably come up with many new interesting ways to improve.
It's a side effect of being so excited about Bitcoin payments.
Congrats!
Do you think Bark has any clear benefits for AI agents over Lightning/ecash?
Yes, the same reason it's better for humans: onboarding is extremely simple. Agents have to deal with the same setup friction for LN/ecash (typically) as humans do. If they have a Bark wallet it only takes downloading a Bark wallet binary and then they're instantly able to do payments.
@stevenroose "Libertarian socialist" is a contradiction. Explain yourself.
Libertarian socialism is the OG libertarianism and anarchism. I think it'd be the only form of anarchism that would actually create a world that I would want to live in.
https://en.wikipedia.org/wiki/Libertarian_socialism
If you are anti-capitalist, why are you the CEO of a company?
Because I'm also a pragmatist. The Ark server has to be run by a company. It can't be realized using open-source grants.
Companies also aren't necessarily capitalist. Capitalism is about rent-extraction through ownership of capital instead of through labor. Our company's software is fully open-source. Our value is in our operation of the Ark server and operations are a perfectly valid reason for a company to exist IMO.
oxymoronism :)
What do you think about René Pickhardt's idea to use Ark as a channel factory?
We think it's the future. But there is quite some work to be done for that to happen.
In the next year, we want to work on having all our users maintain virtual channels with the Ark server. This would be an amazing gain in user experience, especially for trustless receives and exit cost.
Then the next step is channels between individual Ark users that can be used for routing, for example.
We are working both with LDK people to add support there for Bark-based channels and with the Lightning spec working group to make channel gossip support off-chain channels in general!
Random future question: If there were (hopefully) many independent second ark operators/ASPs, could a wallet connect to multiple of them and have a unified balance across them (possibly even Multi-Ark payments like Cashu multi-nut payments)
It'd be a challenging UX problem. Ark balances on different Arks are not compatible, you need to transfer between them using Lightning or an atomic swap. But it's probably as possible as a unified on-chain/off-chain balance now (e.g., unifying on-chain/liquid/lightning channel).
Any plans to support NWC in noah or arke?
No plans yet for Arké. How would you like to use it?
They both have incredibly friendly developers that will surely want to answer your question if you reach out :)
https://arke.cash
https://alpha.noahwallet.io
What do you think will distinguish Bark from arkade or non-ark things like Spark and Cashu?
Sell me on why I should start using Noah or Arké instead of Blitz or Minibits.
It's hard to compare three ways against all those, but the biggest differences are probably our bitcoin focus, we're 100% dedicated to making the absolute best bitcoin payment experience, optimizing for UX and reliability. And we also take our unilateral exit very seriously, we've spent lots of time making sure our unilateral exits ("emergency exits") work client side without any interaction with the server or other third party.
Bark has a nice mascot, but what's up with the triangle for the ark logo?
It was made before we got involved. It's a cool logo, simple and stuff. But come on, Byte is way nicer! Have you seen him jump the hole? https://second.tech/notfound
From a user perspective, how do you think about the difference between a client-server protocol like Ark and something that is more peer to peer like lightning? I'm primarily interested in the trade-offs for a user (eg, I don't have to worry about liveness, but I don't have as strong control over my utxos)?
It's probably strictly better. Self-custodial clients need to get super complex for both devs and users to support all the P2P connections. There's multiple channels, lots of liquidity to worry about. It's like the difference between running your own email server and relying on Proton Mail. Most people will prefer Proton.
The biggest trade-off for an Ark user is probably that unilateral exits will usually cost more to execute. With Lightning it's two on-chain txs per channel, but with Ark it's going to be a few times that on average.
And both have a liveness requirement, Lightning users need to be able to detect combat malicious channel closes.
I definitely see how the liveness requirement of Ark is less intense than the liveness requirement of lightning. It feels like a big improvement there.
But I was thinking about it like this: with lightning, I can create a channel with any peer willing to make a channel with me. And the odds are there will be somebody who is willing to do that. So I can get access into the wider lightning network.
With a client-server relationship like Ark, I could get shut out if the Ark Service Provider doesn't want to serve me. For instance, imagine that I live in Iran and bark doesn't want to get in trouble, so they might potentially geoblock ip addresses from Iran. It seems like the client-server nature of Ark makes it a little less open than lightning.
Yes, lightning is awesome and the protocol is very decentralized.
However, we see that most end-users rely on a lightning service provider (LSP) to use it. In some way lightning is growing into a hub and spoke model. Even many hobbyists that run a lightning node for fun are buying channels from such an LSP.
This risk of geo-blocking for an Ark Server and LSP is quite similar. We need moreArk Servers. But at some point we need more LSPs
PS: All code is public and anyone can run their own Ark Server.
Ark users have the ability to do an emergency unilateral exit that does not require the server to co-sign.
How optimistic are you that Bitcoin will see some sort of covenants soft fork in the next few years?
Work is going on. Slowly but steadily, that's the way to do it in bitcoin.
@darosior and @instagibbs are championing most of the work.
OP_TEMPLATEHASH recently got merged into and activated on the Bitcoin Inquisition signet: https://github.com/bitcoin-inquisition/bitcoin/pull/100
I'm quite positive. It won't happen this year, but I think we will get there!
I can't wait to remove all the cosigning code from our implementation by adopting OP_TEMPLATEHASH. Not even mentioning the exciting new features we could add that are currently simply impossible!
I was looking at satsigner a little. Do you see a future where people have an Ark wallet integrated with their cold storage wallet?
Yes!
The current bark sdk allows developers to bring their own wallet. It is possible to board, offboard or exit directly from nearly any onchain wallet. The sdk uses psbt's which is a common signing format that most hardware wallets support.
However, securing all your offchain coins by a hardware wallet is a technical stretch and I don't see much value for it. You don't need the same level of security for a spending wallet as for the your life savings
What do you hope you all build or someone else builds on Bark in the next year? The next five years?
Bitcoin wallets that my mom can use.
Did you expect lightning adoption to be faster/better? Lightning has been around for a while now and it's gotten pretty good, yet there are still some big pain points and it doesn't seem to be taking the world by storm.
(I guess Square terminal thing is a counterpoint to this)
The pain points have a lot to do with the onboarding experience. You only have a small amount of time when onboarding new users to make a great first impression. Ark makes this part so much better, along with making payments in general much easier.
is it bArk or Bark?
Bark!
Congrats! Personally, I think Ark is a centralized, censorship-riddled distraction.
What was the most surprising thing you've learned working on Bark?
Can I send Ark payments from Second Ark to Arkade's Ark?