We chose honggfuzz over libfuzzer for fuzz testing bark. libfuzzer is simpler to set up, but honggfuzz gives us more flexibility for complex targets down the road. And it's what rust-bitcoin uses, so we can borrow from their what they're doing!
Second
_@nostr.second.tech
npub1ake0...pfwt
Simple solutions for integrating Ark and Lightning payments into your apps. Painlessly deliver fast, low-cost, self-custodial payments to your users.
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.
Ark's transaction trees feel exotic until you realize they're just cleverly arranged standard bitcoin transactions. No special opcodes needed. Just signatures, timelocks, and multisigs held off-chain.
We've released bark-0.1.0-beta.6 featuring hArk (Hash-lock Ark), a major protocol evolution that eliminates synchronous interactivity during rounds. Previously, all round participants had to be online simultaneously to sign intermediate transactions. hArk removes this requirement—the server generates a unique secret for each VTXO, and participants can claim asynchronously after signing a forfeit transaction.
This also enables efficient consolidation of multiple VTXOs into a single output and reduces server costs during malicious exit scenarios.
Note: Wallets created before this release require migration due to security upgrades with hardened key derivations. Create a new wallet and transfer funds before upgrading.
Lots more updates on the changelog: 
Changelog - Second Docs
Updates to Bark, our implementation of the Ark protocol. Including the SDK, wallet, server, and developer tools.
The Ark model of Lightning: Users hold "funds at rest" in VTXOs, then swap into Lightning channels via HTLCs to make payments.
Latest changelog for bark 0.1.0-beta.3 to beta.5 is out!
The biggest addition is barkd—a wallet daemon with RESTful API for node runners and businesses wanting simple automation. We've also made ark-lib WASM-compatible for web environments, replaced the arkoor-depth limitation with checkpoints, and improved Lightning payment reliability.
Full changelog: docs.second.tech/changelog/changelog
Added @Carlos Marques to the team for DevRel. He showed up, immediately fixed up our faucet, and is already close to shipping a Bark web wallet. Also runs bitcoin education content in Portuguese and contributed to @satsigner + @Medusa🪼. Welcome Carlos (follow him for updates!)
Before joining Second, @dunxen did stellar work with @Btrust on Lightning protocol development. Nice profile on his work below.
"Being a grantee at Btrust was, first and foremost, the best grantee experience I had throughout my grant-funded open source development career so far."
Btrust Blog
Celebrating Duncan Dean’s Journey with Btrust
At Btrust, we’ve been fortunate to support developers whose work strengthens the foundations of Bitcoin. Today, we celebrate the journey of Dunca...
Rapid progress being made by @Christoph Ono with his Bark-based Arké wallet, which now has an iOS companion under development to complement the macOS app.
Our software is all open source, with one conspicuous exception. We fixed that today (after a bit of spring cleaning!). The code for our signet faucet and test store is now available on GitLab!
GitLab
ark-bitcoin / faucet · GitLab
GitLab.com
Merry Christmas! Wishing you a peaceful holiday from everyone at Second (and Byte).
Ark is how you prepare and we’re making it easy.
X (formerly Twitter)
grubles (@notgrubles) on X
It's easy for services to get lulled into a sense of comfort during low fee environments in Bitcoin. Those that prepare ahead of time of transactio...
We've been wanting nested MuSig for a while now, so we can distribute Ark server keys and improve security. The problem is, it's specialized cryptographic work that we probably don't have within the team.
Jesse Posner (Vora founder) approached us with a solution: fund a grant for Beulah Evangelin to build it. Beulah's already contributing to secp256k1-zkp, just finished Chaincode Labs' secp256k1 workshop, and is perfect for the job.
So we're funding the grant. Jesse/Vora will provide ongoing mentorship. And Beulah's nested MuSig implementation will go into libsecp256k1-zkp as open source, so any project can use it. It's going to be particularly valuable for layer 2s, e.g., Vora needs it for their Lightning implementation too.
Full details: 
Second Blog
Second partners with Vora to fund nested MuSig
We're funding a year-long grant for Beulah Evanjalin to implement nested MuSig in libsecp256k1-zkp. This is a joint effort between Beulah, Second, ...
We're hiring.
Like tinkering on bitcoin software? We need someone to help us build app prototypes and POCs on Bark. Non-stop "hackathons", publishing open-source, and posting your progress publicly.
Normally bitcoin companies need to be cautious with vibe coding. For this role, we want you to go nuts with it.
More details and application link at @npub1cajs...0pvw: 
Bitcoiner Jobs
Bitcoiner Jobs | The Bitcoin Job Board
Bitcoiner Jobs is the leading career site helping to build the emerging Bitcoin industry and the careers of Bitcoiners within it.
If you're in Mauritius for @`Btrust`'s Dev Day tomorrow, don't miss @`dunxen`'s session on how Bark makes adding self-custodial Lightning to your apps simple.
Some really neat send payment UX going into @Christoph Ono Arké wallet, based on some patterns established in @Bitcoin Design. By integrating with Bark, a wide range of payment formats are available immediately across Lightning, Ark, and on-chain.
Video demo of Arké's send page dynamically reacting to what's held in the clipboard—fewer clicks and less to think about for the user:
Why Rust? Memory safety isn't optional when you're handling people's bitcoin. Type safety catches bugs at compile-time that would be runtime disasters in other languages. Performance matters too when you're processing hundreds of signatures per round.
The LSP business model has issues—high capital requirements, unpredictable revenue, complex liquidity management. Ark servers are simpler to operate and more capital efficient for similar use cases. We expect competition between the two models will drive better services for users.