Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id CBD37C002D for ; Fri, 30 Sep 2022 00:04:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id AEE4783FA5 for ; Fri, 30 Sep 2022 00:04:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AEE4783FA5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.517 X-Spam-Level: X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkOC45krogE8 for ; Fri, 30 Sep 2022 00:04:26 +0000 (UTC) X-Greylist: delayed 00:07:33 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D358783FB2 Received: from mail.wpsoftware.net (s66-183-0-205.bc.hsia.telus.net [66.183.0.205]) by smtp1.osuosl.org (Postfix) with ESMTP id D358783FB2 for ; Fri, 30 Sep 2022 00:04:26 +0000 (UTC) Received: from camus (camus-andrew.lan [192.168.0.190]) by mail.wpsoftware.net (Postfix) with ESMTPSA id 539D040098; Thu, 29 Sep 2022 23:55:07 +0000 (UTC) Date: Thu, 29 Sep 2022 23:56:51 +0000 From: Andrew Poelstra To: darosior , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ud2Vjxoi6HE8P/FY" Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Wallet policies for descriptor wallets X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2022 00:04:27 -0000 --Ud2Vjxoi6HE8P/FY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm really happy to see this discussion. I don't have any comments on the s= pec 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 =66rom me and thanks to Salvatore for exploring this! On Mon, May 09, 2022 at 11:36:47AM +0000, darosior via bitcoin-dev wrote: >=20 > Unrelated question, since you mentioned `musig2` descriptors in this cont= ext. 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 w= ith as little state as a single monotonic counter) or having a RNG which is rel= iable enough that it at least won't repeat values. Because these aren't blockers for all hwws, even if they are blockers for s= ome, I'd really like to see musig2 support in these protocols, or at least for m= usig2 to be considered in their design. =20 --=20 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 --Ud2Vjxoi6HE8P/FY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmM2MMIACgkQxYjWPOQb l8EHRwgAmuWHcPIliFGJWF8joI6u/jAd32ttP/B9x6f4nWe8/7MqtfzJF7dVKvQF 7LKAVtXDy/8eD89I78jMCmGDenPAJwrrlG9zGZg5L6qWHiyPsDp67E7TXul4e3eD Qzqsob062FMsip6vR1jHMpMGDnZ2eyDpFooNNlaAU66kpBCpmOjR64RURPKK7XNY vo3QH9n0B+AGC7BOEc9TIrtrjR9UdhGMCpxYggupRxiwX/KVcjzbTiwGiA8DGM5h 0ZnNLd1vSGv0IBpUisbK2lm1co9tu7LFkXkYFe55nuzn2b3eAH90X5p6d0qwHVBj XvEsbYB4P4cidLS0+3VA9Qvpise+uQ== =zYLG -----END PGP SIGNATURE----- --Ud2Vjxoi6HE8P/FY--