Greetings! Following up on the technical discussion from a few weeks back I’ve just released VTXO-PACK (vpack), a project designed to provide independent verification and visualization for the VTXO ecosystem.
I launched a live tool at vtxopack.org that helps users visualize how their funds are anchored to the blockchain, regardless of the underlying topology. It currently supports both the sequential chains used in bark and fanned-out Merkle trees.
The core is a no_std Rust library (vpack on crates.io) built for WASM and hardware wallet environments. The goal is to give users a way to audit their off-chain state and maintain an independent backup of the data required for a unilateral exit. The code is open source and can be viewed here.
Thanks again to Steven for the context on nSequence and OutPoint identities—it was a huge help in ensuring the verifier accurately reflects the Bark model. Technical critique is always welcome!
I’m a bit confused about your categorization of the two implementations. I am not up-to-date with the latest on Arkade internals, but the description on the side seems like it also applies to Bark
A wide, fanned-out structure where one root supports many users simultaneously.
That’s also how Bark rounds work.
I gave a brief look into the code, I might be missing something, but it seems that you’re only checking if the user’s spend-path exists and is valid, but you are not checking the non-existence of additional (malicious) spend paths.
The security of a VTXO rests on two pilars:
The most straightforward one: the user can get his exit txs confirmed on-chain. You seem to be checking this by checking the txs match the previous txid and the signature on the tx is valid.
Equally important, though: there exist not other spend paths that allows anyone else to contest your exit. In bark we enforce this by making sure the user has all the info required to reconstruct the entire taproot of the exit. It then knows there is only a key-spend path that the user itself is included in and an expiry path that only is available to the server after the expiry time. (With a covenant this becomes a lot easier to do.) For arkoor VTXOs, it can not fully enforce this anymore, but it still enforces that the server is present in all key-spend paths so that it can rely on server honesty for the same guarantee. I couldn’t find an enforcement of this in vpack, did I overlook?
Small other thing, on this line, I think that’s incorrect, we use u8 for sibling_len. For all other lengths, we use CompactSize, that’s been merged in a fairly recent PR.
Hi Steven, thanks again for the deep dive and the technical feedback.
I’ve updated the library to use u8 for sibling lengths and reframed the UI terminology to more clearly distinguish the two implementations. I hope it makes the practical design directions much clearer for a user while being technically precise.
You made a great point about the second pillar of security (path exclusivity). Honestly, I hadn’t accounted for verifying the non-existence of malicious paths yet. I’ve added that as the top priority on the immediate roadmap.
Following up on the technical discussion from earlier—I’ve posted a report on Delving Bitcoin summarizing the forensic deltas in VTXO construction (nSequence, Identity models, etc.) and proposing a ‘Minimal Viable VTXO’ schema for comment. Thanks again for the technical nudges, they have been very helpful. Would love to hear any further thoughts on the thread!
While it’s probably a good idea to have more ways to verify VTXO validity, I’m not sure about the framing of “proprietary environments” and “implementation-coupled custody”. Bark is fully open source and the exit paths are verifiable from the off-chain output data alone. A user doesn’t need to escape some walled-garden environment.
Also with Bark, as Steven says, users get all the information needed to reconstruct the entire taproot of their exit, so they can verify that only the expected spend paths exist (their own key-spend path and the server’s expiry path).
On mempool policy risk, I think this is less of an issue for Bark. We use zero-fee TRUC transactions with P2A outputs for exit paths, meaning users broadcast one level at a time and bump fees via CPFP using 1p1c package relay. Our blog post from when we deployed package relay for exits.
And heads up the company is “Second” and our implementation is called “Bark” (not “Second Tech”!).
Hi Neil, thanks for the candid feedback and for taking the time to review the project.
I completely own the misrepresentations regarding the “proprietary” framing. I let the narrative drift into an adversarial tone that doesn’t reflect the open-source reality of Bark. I’ve added an Author’s Note to the Delving post acknowledging this, updated the naming, and rewritten the vpack README to focus on the core technical problem of lightweight no_std parsing for hardware wallets.
I just posted a more detailed reply over on the Delving thread regarding your points on mempool policy and CPFP.
I strongly believe a neutral, ultra-lightweight parser is important for the L2 ecosystem, and I’d love to continue the technical discussion over on Delving to make sure vpack accurately supports Bark’s architecture. Thanks again to the whole team for the rigorous review.