Re: [bitcoin-dev] Multisignature for bip-schnorr

2018-09-07 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] BIP sighash_noinput

2018-09-26 Thread Jonas Nick via bitcoin-dev
> 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: [bitcoin-dev] BIP sighash_noinput

2018-09-26 Thread Jonas Nick via bitcoin-dev
, 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

Re: [bitcoin-dev] Multi party Schnorr Rust implementation

2018-11-28 Thread Jonas Nick via bitcoin-dev
> 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

Re: [bitcoin-dev] Safer NOINPUT with output tagging

2019-02-08 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] Safer NOINPUT with output tagging

2019-02-09 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] Safer NOINPUT with output tagging

2019-02-09 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation

2020-02-26 Thread Jonas Nick via bitcoin-dev
> 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

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

2020-02-10 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

2020-05-05 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-19 Thread Jonas Nick via bitcoin-dev
> [...] 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

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

2022-02-18 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] [dlc-dev] CTV dramatically improves DLCs

2022-01-25 Thread Jonas Nick via bitcoin-dev
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

[bitcoin-dev] MuSig2 BIP

2022-04-05 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] MuSig2 BIP

2022-05-26 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] MuSig2 BIP

2022-05-23 Thread Jonas Nick via bitcoin-dev
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

[bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures

2022-07-08 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures

2022-07-17 Thread Jonas Nick via bitcoin-dev
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

Re: [bitcoin-dev] MuSig2 BIP

2022-04-28 Thread Jonas Nick via bitcoin-dev
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