From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Erik Aronesty <erik@q32•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Tom Trevethan <tom@commerceblock•com>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Date: Wed, 26 Jul 2023 17:40:26 +0000 [thread overview]
Message-ID: <ZMFaioPPIx3w+HlP@camus> (raw)
In-Reply-To: <CAJowKgJFHzXEtJij4K0SR_KvatTZMDfUEU40noMzR2ubj8OSvA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]
On Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wrote:
> personally, i think *any* time a public key is transmitted, it should come
> with a "proof of secret key". it should be baked-in to low level
> protocols so that people don't accidentally create vulns. alt discussion
> link: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406
>
POSK is not a panacea. For example, if you were to try to eliminate
rogue key attacks in MuSig by using POSK rather than by rerandomizing
the keys, the last person to contribute a key could add a Taproot
commitment to their key, thereby modifying the final key to have a
Taproot spending path that other participants don't know about. If they
did this, they'd have no problem producing a POSK since Taproot
commitments don't affect knowledge of the secret key.
POSKs are also logistically difficult to produce in many contexts. They
essentially require an interactive challege-response (otherwise somebody
could just copy a POSK from some other source), meaning that all
participants need to be online and have secret key access at key setup
time.
In some contexts maybe it's sufficient to have a static POSK. Aside from
the complexity of determining this, you then need a key serialization
format that includes the POSK. There are standard key formats for all
widely used EC keys but none have a facility for this. If you are trying
to use already-published keys that do not have a POSK attached, you are
out of luck.
If your protocol requires POSKs to be provably published, you also run
into difficulties because they don't make sense to embed on-chain (since
blockchain validators don't care about them, and they're twice as big as
the keys themselves) so you need to establish some other publication
medium.
If you want to support nested multisignatures, you need to jointly
produce POSKs, which requires its own protocol complexity.
The MuSig and MuSig2 papers say essentially the same thing as the above;
it's why we put so much effort into developing a scheme which was
provably secure in the plain public key model, which means that POSKs
are superfluous and you don't need to deal with all these logistical
hurdles.
--
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:[~2023-07-26 17:50 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 7:46 Tom Trevethan
2023-07-24 10:50 ` ZmnSCPxj
2023-07-24 14:25 ` Erik Aronesty
2023-07-24 16:08 ` Tom Trevethan
2023-07-24 15:57 ` Tom Trevethan
2023-07-24 14:12 ` Jonas Nick
2023-07-24 14:40 ` Erik Aronesty
2023-07-24 15:40 ` Jonas Nick
2023-07-24 16:51 ` AdamISZ
2023-07-25 14:12 ` Erik Aronesty
2023-07-25 16:05 ` Tom Trevethan
2023-07-26 4:09 ` Erik Aronesty
2023-07-26 17:40 ` Andrew Poelstra [this message]
2023-07-26 19:59 ` Jonas Nick
2023-07-26 20:35 ` Tom Trevethan
2023-07-26 22:06 ` Erik Aronesty
2023-07-27 2:54 ` Lloyd Fournier
2023-07-27 8:07 ` Jonas Nick
[not found] ` <CAJvkSsfa8rzbwXiatZBpwQ6d4d94yLQifK8gyq3k-rq_1SH4OQ@mail.gmail.com>
2023-07-27 13:25 ` [bitcoin-dev] Fwd: " Tom Trevethan
2023-08-07 0:55 ` [bitcoin-dev] " Tom Trevethan
2023-08-08 17:44 ` moonsettler
2023-08-09 15:14 ` Tom Trevethan
2023-08-10 3:30 ` Lloyd Fournier
2023-08-10 11:59 ` Tom Trevethan
2023-08-14 6:31 ` Lloyd Fournier
2023-08-30 10:52 ` Tom Trevethan
2023-07-24 15:39 ` Jonas Nick
2023-07-24 16:22 ` Tom Trevethan
2023-07-26 9:44 ` moonsettler
2023-07-26 14:59 ` Jonas Nick
2023-07-26 19:19 ` AdamISZ
2023-07-26 19:28 ` moonsettler
2023-07-27 5:51 ` AdamISZ
[not found] <mailman.125690.1690381971.956.bitcoin-dev@lists.linuxfoundation.org>
2023-07-26 16:32 ` Tom Trevethan
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=ZMFaioPPIx3w+HlP@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
--cc=tom@commerceblock$(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