BSV Desktop v3.3.1 Releases Live Payments With Receive-Tab Controls

Wallets & Identity / Applications

In Brief

BSV Desktop has published version 3.3.1 as a regular release, bringing live wallet-to-wallet payments over WebRTC to downloadable Windows, macOS and Linux builds.

The release restricts incoming live-payment connections to the Receive tab, incorporates recipient-side transaction broadcasting and corrects a version-response problem that could prevent applications from discovering the wallet.

News Report

The project published v3.3.1 on October 23, 2026, at 12:39 UTC, following the v3.3.0 pre-release earlier that day. GitHub lists Windows installation files, macOS builds for Apple Silicon and Intel processors, and Linux AppImage, DEB and RPM packages.

The desktop release follows the BSV Browser live-payment update covered by BSV TIMES on October 22. It carries its own receiving controls and an additional correction to the desktop application’s BRC-100 connection interface.

Live Delivery With MessageBox Fallback

The sender selects a recipient and an amount, and the wallet first attempts a live WebRTC connection. If the recipient cannot be reached through that route, the interface offers delivery through MessageBox.

A signaling relay helps the wallets find one another. The payment then travels through an encrypted WebRTC channel. Connection setup still uses network services, and the other wallet can learn the sender’s network address.

The release also incorporates a correction to incoming transaction processing. For a transaction without a mining proof, the receiving wallet attempts to broadcast it while importing it, before returning an accepted acknowledgment. The sender’s later submission of the same transaction provides another broadcast attempt without creating a second payment.

When the receiving wallet cannot reach a broadcaster, it can retain the payment locally for retry. The interface distinguishes a payment received but not yet added from one accepted into the wallet balance. A live acknowledgment does not establish that the transaction has been mined.

Receiving Depends on the Open Tab

With live receiving enabled, the wallet answers new incoming connections only while Payments → Receive is selected. Leaving that tab stops new incoming connections while allowing existing sessions to finish.

This narrows exposure compared with the earlier behavior, which answered connections whenever the wallet was unlocked. While receiving is active, someone who knows the wallet’s identity key can still initiate a connection and learn its public IP address without completing a payment.

A minimized or hidden window with the Receive tab selected continues listening. The restriction follows the selected tab, rather than whether the window is currently visible.

The live route also has a one-megabyte transaction-payload limit. The updated sender offers MessageBox for oversized payments before spending through the live route.

The developer reports automated tests for the receiving controls, address-discovery settings and size-limit fallback. The corresponding pull request records that a two-wallet manual check was not run for that change. Moving WebRTC processing into a separate sandboxed component remains identified as follow-up work.

A Specific App-Connection Fix in v3.3.1

The comparison between v3.3.0 and v3.3.1 shows a small but consequential change to the desktop wallet’s getVersion response.

Wallet Toolbox could append capability information to the base version string. According to the source comment accompanying the fix, published SDK wallet clients reject version responses longer than 30 characters during wallet discovery, preventing applications from connecting.

Version 3.3.1 now returns the base version alone through that interface. The correction addresses this discovery response; it is separate from the live-payment transport and receiving controls carried into the release.

BSV TIMES Read

This release advances the practical handling of a payment between two applications: discovering the recipient, delivering transaction evidence, submitting the transaction and explaining whether the receiving wallet has actually added it.

The Receive-tab restriction also makes availability a more deliberate user action. Its value depends on clear disclosure that a listening wallet can reveal network metadata, and that minimizing the window does not switch receiving off.

Developer Context

Darren Kellenschwiler, known publicly as Deggen and using the GitHub account sirdeggen, authored the highlighted live-payment, receiving-control and recipient-broadcasting contributions. His public GitHub profile identifies his affiliation with BSV Association.

Source Links

Posted on October 24, 2026 (UTC)