Sparrow is a desktop wallet that can be used as a networked wallet or a transaction coordinator.
Sparrow is a desktop Bitcoin wallet available for OSX, Windows, and Linux. It is fully featured, and can act both as a transaction coordinator and as a seed generator, seed vault, and cosigner, as the user prefers. It also has extensive interoperability with numerous connected and airgapped hardware wallets.
- Website: https://sparrowwallet.com/
- Repo: https://github.com/sparrowwallet/sparrow
- Downloads: https://sparrowwallet.com/download/
- Documentation: https://sparrowwallet.com/docs/
To most closely cleave to Gordian designs and principles, Blockchain Commons suggests the use of Sparrow as a transaction coordinator, which allows the most highly partitioned usage of the Gordian architecture. In this scenario, keys are maintained on closely held devices, while Sparrow acts as a transaction coordinator that then requests signatures from those devices as required to create transactions.
Under this methodology, Sparrow usage occurs as follows:
- Keys are generated on closely held devices.
- Pubkeys are imported into Sparrow.
- A single-sig or multisig account is created on Sparrow.
- Transactions are generated by Sparrow as PSBTs.
- Transactions are signed by closely held devices as needed.
- Transactions are returned to Sparrow as a fully signed PSBT and then transmitted.
This is not the only possible usage for Sparrow, as it's a fully functional desktop wallet. Keys can also be generated and/or held by Sparrow itself, adding notable Convenience, but potentially decreasing the security of the custody model and opening it up to compromise.
The following discussion of how Sparrow meets Gordian Principles largely refers to the transaction-coordinator scenario. See "Other Scenarios", below, for additional notes on other usages.
Sparrow maximizes independence in all scenarios because it gives users almost total control over where seeds come from and how they're used, as well as how Sparrow operates with the Bitcoin network.
Pros:
- Users can choose to create seeds or import them from a wide variety of connected or airgapped hardware wallets or from certain software wallets.
- Users can choose to sign transactions directly in Sparrow or to hand them off to another device.
- Users can choose to connect to the Bitcoin network via one of several public servers, via a specified Bitcoin Core Server, or via a Private Electrum server.
Neutral:
- The number of choices available through Sparrow can be overwhelming, and users may not know which create optimal security, though the Sparrow web sites does list best practices for increasing security with increasing funds.
Sparrow also offers several interesting privacy advances.
Pros:
- Sparrow accesses nodes or Electrum servers rather than using non-privacy-focused technologies such as SPV.
- Users have free choice of Bitcoin servers, which they can use to minimize Privacy threats such as Correlation or Censorship.
- Sparrow can use Tor for currency exchange lookups.
Neutral:
- Users could choose to further improve privacy by keeping their computer offline, except when transmitting transactions, or by erasing account information from Sparrow when it's not needed, but these solutions sufficiently impact Convenience that they're unlikely to be used.
Cons:
- As a networked computing device, Sparrow is threatened by the largest selection of privacy attacks. Its level of protection ultimately relates to encryption and password protections that also protect against SPOC.
Protecting against Single Points of Compromise (SPOC) can be challenging for a networked device, which is why Blockchain Commons suggests the use of Sparrow as a transaction coordinator. Nonetheless, Sparrow does consider and address the issue.
Pros:
- Accounts are encrypted.
- Accounts can optionally be stored on removable media.
- Individual accounts can be password protected, using Argon2 hashing.
- As a Java-coded apps, Sparrow is more secure than the vulnerable browser extensions that are popular for wallet design.
- Sparrow supports multisigs, with strong ease-of-construction and usage, which can further reduce SPOCs.
- Provided that a quorum of keys are kept offline, per the model of Sparrow-as-transaction-coordinator, Sparrow itself is almost entirely proof against SPOC. This moves the question of SPOC down to the hardware or airgapped wallet.
Neutral:
- Networking computing devices are vulnerable to Network Attacks. Even with keys kept offline, this could theoretically result in corruption of app code or of PSBTs. In those situations, security once more falls to the hardware and airgapped devices, and would be dependent on the quality of their UIs for approving PSBTs.
Sparrow does not have any implicit protection against Single Points of Failure (SPOF).
Pros:
- Account files can be exported, allowing the creation of backups.
Neutral:
- In a transaction-coordinator model, protection against SPOF ultimately falls on the hardware or airgapped wallets holding the seeds.
Cons:
- Password protection of accounts can act as a SPOF.
Supporting a wide variety of specifications is one of Sparrow's strongest features.
Pros:
- Sparrow can interact with most popular connected and airgapped hardware wallets.
- Sparrow can import BIP32 master keys and BIP39 mnemonic words.
- Sparrow supports several UR types.
- Sparrow code is open source.
The other major scenario for Sparrow is using it as a warm software wallet, where it acts in an unpartitioned way, generating and storing seeds, coordinating transactions, and signing them. This causes the following variations to the Gordian Principles:
- Indepedence (Pro): Being able to also use Sparrow as a software wallet creates even more independence.
- Privacy (Pro): Using a warm wallet enables the usage of CoinJoin by having Sparrow act as a client of the Samourai Whirlpool implementation.
- Resilience Against SPOC (Con): Though Sparrow has powerful password and encryption protections, maintaining private keys on a networked computing device is always more dangerous than doing so with a hardware wallet (especially an airgapped hardware wallet). This is the largest danger of using Sparrow as a warm wallet and is why Blockchain Commons instead suggests the use of an airgapped Gordian architecture.
- Resilience Against SPOF (Neutral): If a key is solely held in Sparrow, it can be exported as BIP-39 mnemonic words, using a "View Seed" functionality. This offers a methodology for easily backing up the seed, but it's not strongly presented, and doesn't support more integrated backups (such as Passport's MicroSD backups), nor backup features that offer additional resilience (such as SSKR).
- Openness (Neutral): Obviously, depending solely on Sparrow as a software wallet obviates the needs for a lot of the interoperability specifications, but nonetheless they remain available.
Sparrow offers specific defenses against the following #Smartcustody adversaries. Again, this largely focuses on the transaction-coordinator scenario. See "Other Scenarios", below, for additional notes on other usages.
The biggest threat of Censorship tends to be if a Bitcoin node refuses to process your transactions. Because Sparrow offers so many choices for accessing the Bitcoin network, this problem is largely obviated.
The power of Sparrow as a transaction coordinator is that it has strong ease of use for both creating accounts from keys held by one or more hardware wallets and for creating transactions for those accounts. There's little confusion and no particular time or effort costs. This keeps users from using even more convenient (and less secure) methodologies.
Correlation can come about if a Bitcoin node collects information about your transactions. A user who considered this vulnerability a true risk could either run his own Bitcoin server or regularly switch between others, all of which is easy to do with Sparrow.
As with any true self-sovereign solution, Sparrow minimizes institutional theft, because you hold your keys, not an institute.
Network attack is the largest threat to keys held on networked desktop computers. In a transaction-coordinator scenario, even if an attack succeeded, all that an attacker could secure would be watch-only pubkeys, since the private keys are secured on hardware devices.
The encryption of accounts (if they're not in immediate use for signing) and the optional password protection of accounts together provide good Physical-Theft protection, but even if these obstacles were overcome, again all that the attacker would gain would be watch-only pubkeys in the transaction-coordinator scenario.
The graphical transaction display, which carefully shows inputs and outputs, demonstrates the power of using a full desktop computer; it reduces the odds of Transaction Errors.
The following Adversaries are largely passed off to the hardware wallets holding keys in the transaction-coordinator scenario: Bitrot, Disaster, Key Fragility, Systemic Key Compromise, Supply-Chain Attack.
The following Adversaries are largely unaddressed: Coercion, Death/Incapacitation, Social Engineering.
In the scenario where Sparrow is used as a warm wallet, threats such as Network Attack and Physical Theft become more problematic, requiring the user to ultimately decide on his own risk-tolerance for those possibilities arrayed against the cryptographic and password protections of Sparrow. Fundamentally, this is an example of the Convenience adversary: by using a much more convenient (and potentially cheaper) scenario, the user is potentially put himself at more risk.
Sparrow has been built to be individually interoperable with a large number of hardware and software wallets.
- Sparrow can scan for a variety of connected hardware wallets.
- Sparrow can import QRs and/or files from several airgapped hardware wallets.
- Sparrow can import master private keys (BIP32) and mnemonic words (BIP39).
- Sparrow can import from Electrum keystores.
Sparrow also makes use of URs as appropriate:
- Sparrow can accept the
ur:crypto-hdkeyof a pubkey to create a watch-only account. - Sparrow can exchange a
ur:crypto-psbtwith appropriate devices for signing.
Additional usage of URs could improve interoperability and resilience for URs as well as future-proofing the overall app.
- Import of seeds as
ur:crypto-seedcould be offered as a general choice ("Import through URs"), allowing interface with any wallet supporting the specification. - Seeds could be requested through
ur:crypto-request. This could be particularly useful for the creation of multisigs, with the creation entirely managed by Sparrow, requesting the exact key derivations it needs from other wallets. It would dramatically improve ease-of-use for a multsig creation of this sort. - PSBT signing could be requested through
ur:crypto-requestto offer additional context for transactions. - Seeds could be output as
ur:crypto-seedto offer easy backup or emigration from Sparrow in a robust way that's self-identifying and self-verifying. - Seeds could be output as
ur:crypto-sskrto offer more secure backup, once more in a way that's self-identifying and self-verifying.
Sparrow does its best to make a warm desktop wallet secure by using encryption and passwords. It's a big step up from the increasingly popular wallet browser extensions, and a good choice for users who need the Convenience of having their Bitcoin immediately accessible on their desktop (a situation that runs at odds with the Gordian architecture, which focuses on the partioning of services and data). The biggest dangers of this scenario are the potential for Single-Point-of-Compromise or Single-Point-of-Failure. The SPOCs are implicit to the use of a warm desktop wallet (though it could be reduced by use of Sparrow's simple and intuitive multisigs, but obviously doing so moves away from the core warm-wallet scenario). The SPOFs could be reduced with more varied and interoperable export functionality, and especially by using of Shamir's Secret Sharing, such as is found in SSKR.
Sparrow can also act as a transaction coordinator, where it gathers together pubkeys from hardware wallet devices, creates accounts, and then when money needs to be sent, creates transactions and asks the hardware wallets to sign. This is a powerful scenario that allows for strong protection of seeds while maintaining ease of use. It's Blockchain Commons' recommended use of the wallet. This scenario can be even more powerful if used in conjunction with Sparrow's simple multisig functionality, drawing multiple seeds from multiple hardware devices. Sparrow is sufficiently advanced in this regard that its currently Blockchain Commons' choice for designing a multisig #SmartCustody scenario.