Second's avatar
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.
Second's avatar
second 0 months ago
We caught a capacity overflow bug in Bark before it ever hit a user—thanks to the fuzz testing @luca0x46 has been running around the clock. A malformed VTXO could have requested an arbitrary vec size during deserialization, triggering a panic. Now it's patched. Bark's client-server architecture means the server has to gracefully handle anything thrown at it—malformed VTXOs, malicious client requests, unexpected edge cases. Fuzzing helps make sure the server stays up and keeps serving rounds no matter what comes in. The vec allocation bug is a good example of something easy to miss in review—stable Rust doesn't yet support try_with_capacity, so the bounds check has to be done manually. Our first fuzz target was a straightforward deserialize/serialize pass, and it surfaced the issue immediately. The fuzzer runs 24/7 now, with minimized corpora pushed to our bark-qa repo alongside test vectors used throughout Bark's development. More targets coming—serialization/deserialization expansions first, then method-level fuzz targets. Full writeup: image
Second's avatar
second 1 month ago
Bark's Rust API docs are live on docs(dot)rs. `Wallet` is the central entry point—create, sync, inspect VTXOs, pay Lightning invoices, refresh in rounds, exit unilaterally. All from one struct.
Second's avatar
second 1 month ago
It's probably going to be a process of trial and error to find the optimal refresh strategy for users on Ark. Bark lets each wallet dev implement their own VTXO refresh strategy—set when VTXOs should be auto-refreshed based on expiry, size, or exit cost: image
Second's avatar
second 1 month ago
Bark's `Wallet` struct is the single entry point for Ark, Lightning, and on-chain payments. Create one with a mnemonic + sqlite + server URL and you're transacting. image
Second's avatar
second 1 month ago
The liquidity fee model in Ark is time-based: refreshing a VTXO costs more the further it is from expiry. This creates natural incentives to refresh closer to deadline rather than early.
Second's avatar
second 1 month ago
On-chain payments on Bark no longer happen in rounds. They're now instant, kind of like Ark-to-onchain swaps. This makes them more expensive than before, but the upside is that they're now broadcast immediately (more intuitive UX).
Second's avatar
second 1 month ago
Generating Ark addresses offline is now feasible with persisted server pubkeys. No need to be connected to the Ark server just to produce a receive address.
Second's avatar
second 1 month ago
Payments on Bark currently use a single input. Instead of multi-input txs, large txs bundle independent arkoor txs into a "package" sent to the receiver in one go. Wallet history shows it as a single incoming payment.
Second's avatar
second 1 month ago
Small Rust API design lesson from Bark development: if your top-level functions are just thin wrappers around methods on a struct, they shouldn't exist. Put the logic where it belongs.
Second's avatar
second 1 month ago
If you're building on the Bark library, Lightning payments are now `wallet.pay_lnaddr(..)` instead of standalone functions that take a wallet reference. Smaller surface, fewer surprises.
Second's avatar
second 1 month ago
We're building a shared corpus repository for our fuzz targets. Every time the fuzzer runs, it builds up optimized inputs that make future runs more efficient—it doesn't start from zero each time. Over time this becomes an automatically growing collection of edge cases that doubles as regression testing.
Second's avatar
second 1 month ago
1/ Getting honggfuzz running inside a Nix development shell was its own adventure. Nix's hardening flags conflict with how honggfuzz instruments binaries, and glibc version mismatches between NixOS and honggfuzz added another layer.
Second's avatar
second 1 month ago
Fuzz testing throws massive volumes of random and malformed data at your code to find crashes that normal testing misses. @lucad70's been adding it to our QA process and it's already caught arithmetic overflows and unwrap panics that could crash the server. Fuzzing is pretty much a requirement when you're building protocol-level software.
Second's avatar
second 1 month ago
Bitcoin scaling has two sides: transactions in blocks and UTXOs. Lightning scales transactions. Ark scales both.
Second's avatar
second 1 month ago
We've redesigned how Bark-based wallets sync with the Ark server. The new unified mailbox replaces per-address polling with a single feed for all wallet notifications (Ark and Lightning payments, refreshes, and more) with support for real-time push subscriptions. One endpoint, checkpoint-based sync, and delegated notification auth for mobile. Available now in Bark.
Second's avatar
second 1 month ago
Refreshes on Bark no longer use connectors for atomicity, that's now handled by good ol' hash-locks. Confusingly, on-chains payments now use connectors instead, which are no longer handled alongside refreshes!
Second's avatar
second 1 month ago
Bark's new unified mailbox consolidates all wallet notifications into a single feed: Ark payments, Lightning preimages, BOLT-12 offers, and refresh completions. Checkpoint-based sync fetches only what's changed. image
Second's avatar
second 1 month ago
Taproot happened because Lightning proved the need for it. The best way to get covenants is for Ark to prove the need for them too.
Second's avatar
second 1 month ago
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!