Bitcoin Headless Signers

Random idea I had awhile ago on this concept that I've been calling headless signers. It's not lightning related so may not be idea for LOL tourny but figured I'd share it anyways.

Copied from my site https://www.docsharp.xyz/

TL;DR: Headless signers allow users to get the UX benefits of collaborative custody whilst maintaining better privacy, security, and interoperability.

Collaborative custody models used by Unchained Capital, Casa, Green wallet, and soon Block, offer a non-custodial, secure, and user-friendly way for people to save in bitcoin. Though these services (besides Block for now which details aren't fully clear yet) come with issues around privacy, security and interoperability.

Unchained has a great page explaining exactly what collaborative custody is here. I'd recommend reading this before continuing.

Collaborative custody trade-offs

• Not Free and open-source (FOSS). Services like Casa and Unchained use closed source applications which means users are trusting them that the code is secure and they aren't doing anything shady. This is a major security risk and considering these services are safeguarding people's life savings this is a trade-off that should not be taken.

• Your wallets balance, IP, and entire transaction history is shared with these third party services. This is valuable data that should be private. Although they can't censor or steal your bitcoin directly, knowing intricate details about you and your bitcoin can be used as an attack vector to censor you in meat space or freeze your bitcoin.

• To get the UX benefits of collaborative custody you are restricted to using the front ends offered by said services. One of bitcoins defining principles is interoperability and decentralization of which this goes against.

How headless signers work

Before detailing how headless signers may solve the above issues, it's important to understand how they could work in practice.

Below is an overview of how a headless signer service (HSS) could be used. I stuck with only covering an individual's wallet setup and not a shared collaborative custody wallet (where multiple people all control the bitcoin in the wallet) as this adds some additional complexity.

1. A user purchases an xpub from a trusted HSS which is sent to them over a secure communication channel.

   • This whole process could be automated with a standardised way for FOSS front ends to interface with HSS's and conveniently retrieve xpubs.
   1. The HSS generates unique seeds for each user and shares the associated xpub of that seed with the user.

2. Users construct a multisig wallet using any front end they want (this is where the headless part comes from) using their own xpubs and xpubs purchased from the HSS.

   • For example's sake I am going to assume this user is constructing a 2 of 3 mulitisig wallet.

3. If / when the user needs to have the HSS sign a transaction they can pass a PSBT for them to sign with their 1 of 3 key.

   • As mentioned above, if a standardised way exists for this PSBT to be shared then this could be automated by the FOSS front end.

   • This would only be done in the event of the user losing 1 of 3 of their keys and the HSS service would assist them in rotating to a new wallet in which the user has control of 2 of 3 of the keys again.

   • May need to establish some kind of secret or official communication channel (such as an email) between user and provider when the xpub is purchased so they aren't blindly signing something they shouldn't be.

   • This may incur extra costs for the user depending on the HSS.

Headless signers benefits

• Can use any FOSS front ends. As mentioned above, not having FOSS managing your savings is a big security risk.

• A HSS only shares an xpub with the user and has no connection to their wallet so they will not know the wallets balance, IP, or transaction history. This privacy benefit is nullified to some degree if the HSS is used (see step 3 above).  Though with headless signers the user has more options and control over who that headless signer is. It could even just be a trusted friend or family member. Privacy is not secrecy and giving users the power to decide WHO can see their data is important.

Edit 9th September 2022: These privacy benefits are only obtained by using Taproot.

• Any combination of front end and HSS can be used. This makes things more interoperable and decentralised by giving users the power to decide what software they run and who they trust.

• Similar to the above point, having a wide array of front end options available to users means more signing tools can be used. Collaborative custody services often do not support every external signer on the market for example. Again, the more choices the user has, the better and more secure their setup can be.

• Combining a HSS with FROST would make it easy for users to rotate keys without any extra on-chain transaction cost.

• Could be a potential revenue stream for FOSS providers.

Trade-offs using Headless signers

• If the user loses both of the keys they hold this model would most likely be impossible for recovery to occur. This would require the FOSS tools to have some kind of system in place for this scenario which isn't entirely implausible.

• Headless signer could refuse to sign a transaction or lose access to their signing key essentially freezing your bitcoin if you lose one of your keys. Though this is an issue with all collaborative custody services.

Other use cases

• Headless signers could be used by Fedimint federations to act as neutral third-parties that can step in when necessary to audit bitcoin reserves or resolve disputes.

Summary

In summary, a HSS could improve on the UX of FOSS tools like Nunchuk or Bitcoin Core by combining elements of collaborative custody services like Casa in a more secure, private, interoperable, and decentralized manner.