pull down to refresh
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.
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.
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.
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.
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.
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!
They both have incredibly friendly developers that will surely want to answer your question if you reach out :)
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.
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.
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
- Just a little longer than half a year ago I stated that Unless both Ark implementations fumble the ball, Spark is going to eat everyone's lunch. and today we are seeing that Spark has gotten a big headstart by becoming the defacto Lightning backend to many self-custody wallets, how do you guys think you will be able to reclaim the room taken by it? In the end the main reason why is has been implemented is because it simply works and it is very simply to implement in a wallet, what's your response as a product?
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.
- While working on Bark with the current consensus rules, what has been for the team the biggest challenge so far?
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 :)
- I've seen you guys making the impossible possible by finding a way to bring hArk to life without needing CTV or Covenants in general or finding a way to (almost) decentralize operations, so the concrete question is which of the innovations done by Bark is the most important in the team's opinion?
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.
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.
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!
Hahaha, no, we definitely don't expect to have the same parameters for mainnet. We are thinking of an expiry time of somewhere around one or two months for an Ark with real bitcoin.
Payments and other interactions within the Ark rely on the server. But all users have a unilateral exit package for each VTXO that they can broadcast if the server disappears or goes rogue.
The protocol plans around round times drastically changed. We (Second) are currently thinking about 1 hour rounds, more or less. But you would only use rounds to refresh your own VTXOs when they are about to expire. To send payments, you can your arkoor or out-of-round transactions that are instant.
(But don't worry the above signet Ark server does rounds every 10 seconds.)
When it comes to doing coinjoin rounds, that's currently not implemented.
Bitcoin wallets that my mom can use.