Hello,
Today we'd like to announce the release of version 0.4.1 of libsecp256k1:
https://github.com/bitcoin-core/secp256k1/releases/tag/v0.4.1
This release slightly increases the speed of the ECDH operation and
significantly enhances the performance of many library functions when using the
It is true that BIP 327 ("MuSig2") does not include adaptor signatures. The
rationale behind this decision was as follows:
- the BIP is already long and complicated enough without adaptor signatures; it
should be possible to propose a separate adaptor signature BIP on top in a
modular fashion
No, proof of knowledge of the r values used to generate each R does not prevent
Wagner's attack. I wrote
> Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>c[0] + ... + c[K-1] = c[K].
You can think of this as actually choosing scalars r2[0], ..., r2[K-1] and
define R2[i] = r
None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
attack on the nonces, I mentioned an attack on the challenge c) can be prevented
by proving knowledge of the signing key (usually known as proof of possession,
PoP).
___
bitcoin-d
While this may solve blinding, I don't see how it solves the problem that the
client can forge signatures because the client is in control of challenge e'.
This is not special to MuSig(2), but is also the reason why original blind
Schnorr signatures are insecure (as demonstrated in David Wagner's
Not sure what "posk" is or how it relates to the attack.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> Party 1 never learns the final value of (R,s1+s2) or m.
Actually, it seems like a blinding step is missing. Assume the server (party 1)
received some c during the signature protocol. Can't the server scan the
blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as in
signatur
Hi Tom,
I'm not convinced that this works. As far as I know blind musig is still an open
research problem. What the scheme you propose appears to try to prevent is that
the server signs K times, but the client ends up with K+1 Schnorr signatures for
the aggregate of the server's and the clients k
We updated the MuSig2 BIP draft to fix the vulnerability published in an earlier
post [0].
We also wrote an article [1] that contains a description of
1. the vulnerable scheme (remember that the original MuSig2 scheme is not
vulnerable because it doesn't allow tweaking)
2. an attack against th
It is still true that cryptography is hard, unfortunately. Yannick Seurin, Tim
Ruffing, Elliott Jin, and I discovered an attack against the latest version of
BIP MuSig2 in the case that a signer's individual key A = a*G is tweaked before
giving it as input to key aggregation.
In more detail, a si
Since the initial publication of the BIP draft, we incorporated feedback from
this mailing list and the development git repository and made significant
improvements compared to the initial version. There are multiple implementations
today, and there have been no requests for major changes or featu
To be clear, whether "half aggregation needs a new output type or not" does not
become clear in the draft BIP because it is out of scope. Half-aggregation has a
few possible applications. The draft only specifies the cryptographic scheme.
The StackExchange post you link to argues that CISA requir
Half-aggregation has been mentioned several times on this list in various
contexts. To have a solid basis for discussing applications of half-aggregation,
I think it's helpful to have a concrete specification of the scheme and a place
for collecting supplemental information like references to cryp
Thanks for the detailed feedback. Let me try to summarize your argument: Key
aggregation should fail if there are duplicate keys because this is likely a bug
and continuing might be dangerous. If it is not a bug but a dishonest signer
trying to disrupt, then resuming the protocol and trying to ide
Thank you for taking the time to look at the BIP and reference code, waxwing. I
don't know if you're overlooking anything, so let me try to restate the
paragraph in the BIP draft that attempts to cover this topic [0].
Suppose signers would just abort in the presence of identical public keys. In
t
Happy to hear that the BIP draft is already useful and thank you, Laolu, for
extracting the test vectors.
> an implementation must make the _pre tweaked_ combined key available to the
caller
To apply the Taproot tweak with the key aggregation algorithm as specified you
would have to do the foll
Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would like
to propose to the community for discussion. The BIP is compatible with BIP340
public keys and signatures. It supports tweaking, which allows deriving BIP32
child keys from aggregate keys and creating BIP341 Taproot outp
On the topic of half aggregation, Chalkias et al. gave a convincing security
proof last year:
https://eprint.iacr.org/2021/350
As an aside, half aggregation is not exactly the scheme in the OP because that
one is insecure. This does not affect Zmn's conclusion and was already
pointed out in the o
Thank you, that's an interesting application of OP_CTV.
Perhaps worth pointing out that this does not require OP_CTV but could also be
enabled by other covenant constructions. For example, it seems like
ANYPREVOUT-based covenants provide similar benefits. The script of the Taproot
leaves could be
> [...] we can use 2-party ECDSA to create 2-of-2 multisignature addresses that
> look the same as regular single-signature addresses[2]. Even the old-style
> p2pkh addresses starting with 1 can be CoinSwap addresses.
Probably worth considering that p2pkh, p2wpkh and p2sh are vulnerable to the
(we
This is a reasonable suggestion. Committing to every spent scriptPubKey and
therefore every element of the TxOut instead of just the amount makes sense
conceptually. And it would be a small diff (~4 lines + rationale) compared to
the current bip-taproot version.
As far aas I understand, coinjoin w
> Let me put change (1) into my own words.
Correct, except that the speedup from is_even(y) over is_quadratic_residue(y)
affects signing and not keypair generation.
> With change (2), I feel like including this auxiliary random data is overkill
> for the spec. [...] I feel similarly about hashing
I agree with most of the comments so far, but the group brings up an often
overlooked point with respect to the privacy benefits of taproot. In the extreme
case, if there would be no policies that have both a key and a script spend
path, then taproot does not improve anonymity sets compared to the
r fragments and create a
> valid spendable factory-level transaction that effectively kicks out the
> malicious parties, while leaving the rest of the factory as it was. To the
> best of my understanding, the eltoo original
> proposal also allows this though.
>
> Bes
Johnson's modification solves the issue I pointed out.
Moreover, as Johnson and I discussed in private, using different locktimes for
X and Y is not necessary. They can have the same relative locktime. If A and B
would only sign Y as soon as the update tx is confirmed, there is no risk of Y
changi
Output tagging may result in reduced fungibility in multiparty eltoo channels.
If one party is unresponsive, the remaining participants want to remove
the party from the channel without downtime. This is possible by creating
settlement transactions which pay off the unresponsive party and fund a ne
> For deterministic nonces, you generate r=H(p,m) based on the message
> being signed and your private key, so can only start this process when
> you start signing, and the sharing rounds mean interactivity.
It's not your point but it should be noted that this is not secure unless all
other signer
On 9/26/18 7:45 PM, Johnson Lau wrote:
> In BIP143, the nSequence of the same input is always signed, with any
> hashtype. Why do you need to sign the sequence of other inputs?
>
>> On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev
>> wrote:
>>
>>> At the r
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
There is a good reason for not doing that. If NOINPUT would sign the
hashSequence then it would be possible to get rid of OP_CSV in eltoo update
scripts. As a re
Your multisignature writeup appears to be vulnerable to key cancellation
attacks because the aggregated public key is just the sum of public keys (and
there is no proof of knowledge of the individual secret keys). Therefore, in a
multisignature between Alice and an attacker, the attacker can choose
30 matches
Mail list logo
