public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
To: Jeremy <jlrubin@mit.edu>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage
Date: Wed, 26 Feb 2020 12:26:44 -0800	[thread overview]
Message-ID: <CACrqygC0ONobnotfoM60F88xY-vm+v9kjO-A1_brMfSayjQKXg@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhgP=9-AvMOVO+-b9c3DZ_vYd-bPLYM26Qvawmcj28UOZw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3387 bytes --]

On Wed, Feb 26, 2020 at 11:56 AM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As a replacement for paper, something like this makes sense v.s. what you
> do with a ledger presently.
>
> However, shamir's shares notoriously have the issue that the key does
> exist plaintext on a device at some point.
>
> Non-interactive multisig has the benefit of being able to sign
> transactions without having keys in the same room/place/device ever.
>

I agree that that interactive multisig is best for transactional recovery,
but there is still a place in our tool chest for Shamir split backups
especially in operational security scenarios, but as you state, you must be
aware of the limitations of Shamir, not only from the fact that there is
vulnerability in that you must restore keys in one place, but also there
are denial edge cases where when you only have k-1 of n, someone can deny
you knowledge of who gave you the corrupted share.

Right now the best C-library for Shamir sharding of recovery seeds is at
the Blockchain Commons Github
https://github.com/BlockchainCommons/sss/blob/master/README_slip39.md however,
this code base needs refactoring to be a good standalone library. This
requires us separating out the Shamir portions from the SLIP-39 mnemonic
elements and command-line elements. We also want to separate out the
randomness portions of the code so you can test different implementations
against deterministic randomness to ensure they give the same value (but
don't use this for production!) Once this is complete, we will be
submitting this library for formal review.

We are also working on air-gapped open-source open hardware for seed
creations and Shamir restoration. For instance, this device has no wifi,
Bluetooth, or persistent memory, and the serial port is disabled. It is
sized to fit in a bank safe deposit box. See
https://twitter.com/ChristopherA/status/1175465994644574208?s=20

[image: image.png]

Longer-term for seed sharding, we want to leverage the VSS (Verifiable
Secret Sharing) that future Bitcoin musig uses, which we believe has
advantages over Shamir Secret Sharing. It can be used for both traditional
sharding, but also for musig transactional recovery without restoring of
master seeds on a single device, and it is easier to prove that shares are
live and avoid denial use cases.

All this being said, we recommend Bitcoin multisig transactions as the best
solution for self-sovereign recovery of funds vs using Shamir (or SLIP39).
Lately, we've been working on PSBT and bitcoind descriptor support in our
alpha bitcoin wallet for iOS, FullyNoded 2
https://github.com/BlockchainCommons/FullyNoded-2 — in theory, this iOS
wallet can facilitate any scenario that bitcoind supports as a descriptor
as it communicates with your own private full-node over Tor v3.

P.S. If you've not seen it yet, our free #SmartCustody book
http://bit.ly/SmartCustodyBookV101 offers what we think are current best
practices for single seed recovery. We did not include multisig scenarios
in v1 of this book as at the time they were too difficult and error-prone
for most people. We are now working on v2 of the book which will cover
multisign and fiduciary scenarios now that PSBT is maturing and more
wallets are improving multisig support.

— Christopher Allen

[-- Attachment #1.2: Type: text/html, Size: 4640 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 4330187 bytes --]

  reply	other threads:[~2020-02-26 20:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 13:02 [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage Contact Team
2020-02-26 19:56 ` Jeremy
2020-02-26 20:26   ` Christopher Allen [this message]
2020-02-28 13:10     ` ZmnSCPxj
2020-03-06 11:11   ` Russell O'Connor
2020-08-03 22:49     ` [bitcoin-dev] On the compatibility of Bech32 and Shamir's Secret Sharing Russell O'Connor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACrqygC0ONobnotfoM60F88xY-vm+v9kjO-A1_brMfSayjQKXg@mail.gmail.com \
    --to=christophera@lifewithalacrity.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jlrubin@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox