A critical bug in the bsv-sdk Ruby library’s ARC broadcaster misleads developers into believing invalid or rejected Bitcoin SV transactions succeeded. Since version 0.1.0, released February 8, 2024—commit a1f2e62—the code ignores key failure signals like INVALID, MALFORMED, MINED_IN_STALE_BLOCK, and any ORPHAN mentions in responses. Apps relying on this for confirmations risk processing payments or minting tokens on ghosts. CVSS scores it 7.5 High for integrity violations.
The Core Defect
In lib/bsv/network/arc.rb, lines 74-100, the failure check only flags REJECTED and DOUBLE_SPEND_ATTEMPTED. Anything else—from malformed transactions to orphans in stale blocks—returns as a success to the caller. This diverges from the TypeScript reference SDK, which catches those extras explicitly.
ARC, a BSV service for reliable transaction propagation, responds with precise statuses. BSV’s network emphasizes high throughput for tokens like ARC-20 (BSV’s Runes equivalent), where broadcasts must confirm before workflows advance. Ignoring these signals skips validation entirely.
Compounding issues include wrong Content-Type: Ruby sends application/octet-stream, while TypeScript uses application/json with a { rawTx: } body. Missing headers like XDeployment-ID, X-CallbackUrl, and X-CallbackToken break protocol compliance. A single patch fixes all, but the status oversight poses the real threat.
Why Developers Get Burned
Applications gate critical actions on broadcast success: e-commerce releases goods post-payment, wallets mark invoices paid, token minters proceed to transfers. Here, a MALFORMED tx from bad encoding or an ORPHAN from a fork fools the app. Downstream gems amplify this—your invoicing library calls the SDK, gets greenlit, and funds vanish.
CVSS breakdown nails it: Attack Vector Network (AV:N), no privileges (PR:N), low complexity (AC:L)—just broadcast junk. Integrity High (I:H) as decisions hinge on lies; no confidentiality or availability hits. Score: 7.5. In BSV’s low-fee, spam-tolerant chain, attackers craft invalids cheaply. Even honest forks trigger orphans, tricking high-volume apps.
This matters because BSV pitches enterprise-scale: 1M+ TPS claims, real-world assets via sCrypt. SDKs like bsv-ruby target devs building payments, DeFi. One flawed broadcast check erodes trust. We’ve seen similar in Ethereum—MEV bots exploit broadcast races—but BSV’s centralization risks amplify SDK reliance. Users expect libraries to mirror reference impls; this gap invites exploits.
Skeptical take: BSV’s niche (market cap ~$1B vs BTC’s $1T+) limits blast radius. But gems propagate fast—check dependents on RubyGems. If you’re on affected versions, audit calls to BSV::Network::ARC. Test with mock ARC responses: fire an INVALID and watch it pass.
Scope and Response
Affected: All from v0.1.0 onward, introduced in that February commit. No upper bound specified, so assume latest until patched. The advisory patches the predicate to match TypeScript, adds headers, fixes MIME.
Fix now: Pin to patched release or fork. For BSV devs, validate txids independently via node RPC—getrawtransaction confirms mining. ARC callbacks help, but SDK must propagate failures first.
Broader lesson: Crypto SDKs lag chains. BSV’s ARC-20 hype (millions inscribed) demands robust tools. Reference TypeScript works; Ruby didn’t. Devs, always diff against refs. Networks like BSV, pushing tokens amid BTC dominance wars, can’t afford integrity holes—exchanges delist, users flee.
Bottom line: Update. Test broadcasts. In security, silence on failure equals success for attackers.
