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
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
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
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
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
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
> [...] 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
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
> 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
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
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.
>
> Best,
>
> Alejandro.
>
> [1]: Scalable Lightning Factories for Bitcoin,
> htt
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
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
> 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
, 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 risk of bikeshedd
> 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
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
17 matches
Mail list logo
