From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Lloyd Fournier <lloyd.fourn@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hash function requirements for Taproot
Date: Wed, 04 Mar 2020 23:29:09 +0000 [thread overview]
Message-ID: <tXbP-9UVzs4Je3MdjTYAbm0ZWVMctlhY15v6_G8CCRnaWJjo8VU8h2WDfUSiqnWl8rQa0zbrsupNRNtss0gDFjMiqwNil_ahiqSraICAP9Q=@protonmail.com> (raw)
In-Reply-To: <CAH5Bsr2m3+kN67h0Dd+60-i3WCnCRXr_ywzub5_OV=UxxzN3hQ@mail.gmail.com>
Good morning LL,
Thank you very much for this work, it seems quite interesting.
> 5. You can completely circumvent this result by using coin-tossing rather than MuSig for the key generation protocol. In most cases this doesn't even add any extra rounds of communication since you are doing 3-round coin tossing to choose the R values for the signatures that spend from the joint output anyway. You can just toss your public keys in parallel.
I am uncertain what you mean here by "coin-tossing".
From the comparison to MuSig, I imagine it is an interactive key generation protocol like this:
* Everybody generates fresh keypairs.
* Everybody sends the hash of their pubkey to everyone else.
* After receiving a hash of pubkey from everyone else, everybody sends their pubkey to everyone else.
* They add all their pubkeys to generate the aggregate key (and if using Taproot, use it as the internal key).
Is that correct?
In any case, the comparison to MuSig signing appears to imply interactive key generation.
The advantage of MuSig is that it requires no interactivity for key generation of n-of-n (I am told it requires interactivity to generate k-of-n).
However, it can generally be pointed out that, before you put anything into an n-of-n, you would damn well sure want to have *some* assurance that you can get it out later.
So in general you would need coordination and interaction anyway to arrange getting into an n-of-n in the first place.
On the other hand, it would be best to have at least some minimum of privacy by always interacting over Tor and having a Tor .onion address, which has absolutely horrid latency because human beings cry when peeling onions.
So in general reducing the latency by reducing communication rounds is better in general.
Counter to this, assuming you use an n-of-n in an offchain protocol of some sort, the number of communication rounds to generate the aggregate key may be dwarfed by the total number of communication rounds to create signatures to update the offchain protocol.
Counter counter to this is that one plan for reducing communications rounds for creating signatures during offchain operation is to (haha) use a Taproot with an n-of-n internal key and a tapscript that has n `OP_CHECKSIG` operations, so that for normal operation you just toss individual signatures at each other but at termination of the offchain protocol you can do the heavy MuSig-style signing with the n-of-n aggregate key.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-03-04 23:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 7:10 Lloyd Fournier
2020-03-04 23:29 ` ZmnSCPxj [this message]
2020-03-05 9:56 ` Lloyd Fournier
2020-03-12 17:04 ` Tim Ruffing
2020-03-16 7:31 ` Lloyd Fournier
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='tXbP-9UVzs4Je3MdjTYAbm0ZWVMctlhY15v6_G8CCRnaWJjo8VU8h2WDfUSiqnWl8rQa0zbrsupNRNtss0gDFjMiqwNil_ahiqSraICAP9Q=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lloyd.fourn@gmail$(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