From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: darosior <darosior@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wallet policies for descriptor wallets
Date: Thu, 29 Sep 2022 23:56:51 +0000 [thread overview]
Message-ID: <YzYww1keXKYoX2tk@camus> (raw)
In-Reply-To: <osdF1jSCUyGyaLZ6YytSB7ub1MwdbaP6PMCYEJZXmMRaSs4vS7bs_SZTErxZh_K7oLYLAtAqqgl0Vcdl1ftAusM_1DHSDHtz1kSUzqnmwsk=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
I'm really happy to see this discussion. I don't have any comments on the spec
because I think I'd have to be more in-the-weeds trying to implement a hww to
understand how well it works for realistic use cases. But a strong concept-ACk
from me and thanks to Salvatore for exploring this!
On Mon, May 09, 2022 at 11:36:47AM +0000, darosior via bitcoin-dev wrote:
>
> Unrelated question, since you mentioned `musig2` descriptors in this context. I thought Musig2 wasn't really
> feasible for hardware signing devices, especially stateless ones. Do you think/know whether it is actually
> possible for a HW to take part in a Musig2?
>
As Salvatore mentioned in his reply, there are a couple ways that hwws can deal
with musig2 -- specifically, having state (and I believe you can get away with
as little state as a single monotonic counter) or having a RNG which is reliable
enough that it at least won't repeat values.
Because these aren't blockers for all hwws, even if they are blockers for some,
I'd really like to see musig2 support in these protocols, or at least for musig2
to be considered in their design.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-09-30 0:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 14:32 Salvatore Ingala
2022-05-08 17:41 ` Billy Tetrud
2022-05-09 11:36 ` darosior
2022-05-10 9:37 ` Salvatore Ingala
2022-09-29 23:56 ` Andrew Poelstra [this message]
2022-05-17 8:44 ` Salvatore Ingala
2022-11-21 11:27 ` Salvatore Ingala
2023-01-23 19:53 ` darosior
2023-01-24 8:38 ` Salvatore Ingala
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=YzYww1keXKYoX2tk@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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