On Fri, Mar 13, 2020 at 4:04 AM Tim Ruffing wrote:
>
> I mean, the good thing is that there's a general method to defend
> against this, namely always adding a Merkle root on top. Maybe it's
> useful to make the warning here a litte bit more drastic:
>
https://github.com/sipa/bips/blob/bip-taproot
Hi Lloyd,
This is great research, thanks for this effort!
Here are some comments:
On Wed, 2020-03-04 at 18:10 +1100, Lloyd Fournier via bitcoin-dev
wrote:
>
> Property (2) is more difficult to argue as it depends on the multi-
> party key generation protocol. Case in point: Taproot is completel
> 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
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
Hi List,
I recently presented a poster at the Financial Cryptography conference
'2020 which you can find here:
https://github.com/LLFourn/taproot-ggm/blob/master/main.pdf. It attempts
to show the security requirements for the tweak hash function in Taproot.
In this post I'll give a long descripti
