Update on Nested MuSig2: Beulah Evanjalin's proposal is now available as a BIP. It's going to enable lots of cool multisig and multi-device setups for Ark and Lightning wallets, plus more efficient Lightning channels inside Ark. We'd appreciate any review we can get on this:

GitHub

BIP Draft: NestedMuSig2 for BIP340-compatible Signatures by BEULAHEVANJALIN · Pull Request #2297 · bitcoin/bips

This PR proposes NestedMuSig2 for BIP340-compatible Signatures, a BIP draft extending BIP327 MuSig2 to support trees of nested signing groups. Each...

Payjoin boards are now available in Bark and enable a wallet app to receive a Payjoin and board onto Ark in the same transaction, saving the user fees and time. The same trick can also be used to on-ramp onto a Cashu mint running Bark, no channel management required. It may also be the first example of Transaction Cut-Through bitcoin has seen, a 13-year-old idea from Greg Maxwell! More details on the blog:

Second

Board Ark (and ecash mints) with Payjoins | Second Blog

Payjoin boards are now supported in Bark. As of version 0.6.2, a wallet app can receive a Payjoin and board the proceeds into an Ark in the same tr...

Bark 0.5.0 is out, and it delivers one of our most requested features. A wallet's full off-chain balance can now be restored from its mnemonic alone, retrieved from the server. Lightning receives can now land on external Ark addresses, unlocking non-custodial Lightning address servers (thanks to Ben Carman for this work), and delegated refreshes can be scheduled ahead of time, when they're cheaper. Note that boarding now requires bark 0.5.0, so upgrade your clients to keep boarding. Full changelog:

Second Docs

Changelog - Second Docs

Updates to Bark, our implementation of the Ark protocol. Including the SDK, wallet, server, and developer tools.

@Christoph Ono has put together a walkthrough of how he presents emergency exits to users ("forced move") in Arké. He's a master of user-friendly bitcoin UX, so there are valuable tips for anyone building Bark into their app.

We've been doing some research on client-side Lightning pathfinding for Bark wallet apps. Instead of the Ark server working out the best payment route on the user's behalf, the wallet app builds the route and the payment onion itself, so the destination is not shared with the server and potentially eliminating minimum fees on Lightning transactions. Full findings, link to proof of concept, and areas for further research:

Second

Teaching Bark to find its own way through Lightning | Second Blog

Bark wallets can now find their own way through Lightning. Our new, optional client-side pathfinding takes the Ark server out of routing decisions.

Bark 0.4.0 is out, and receiving just got simpler: one BIP 321 payment request covers Ark, Lightning, and on-chain, built in a single barkd call or straight from the SDK. Also in this release: fee quotes for on-chain payments before you send, wallet notifications without a websocket, control over exactly which VTXOs a payment spends, and crash safety across every payment operation. Full changelog:

Second Docs

Changelog - Second Docs

Updates to Bark, our implementation of the Ark protocol. Including the SDK, wallet, server, and developer tools.

The Ark protocol is not constrained by the need to standardize across implementations like Lightning. This means that each implementation is react fast to users' needs.

Kept you waiting, huh? (We're finally on Nostr)