Christopher Allen [ARCHIVE] on Nostr: š Original date posted:2020-02-26 š Original message:On Wed, Feb 26, 2020 at ...
š
Original date posted:2020-02-26
š Original message:On Wed, Feb 26, 2020 at 11:56 AM Jeremy via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200226/55bd31cd/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4330187 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200226/55bd31cd/attachment-0001.png>;
š Original message:On Wed, Feb 26, 2020 at 11:56 AM Jeremy via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200226/55bd31cd/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4330187 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200226/55bd31cd/attachment-0001.png>;
