12020-02-25T01:22:53  *** mol has joined ##taproot-bip-review
 22020-02-25T01:25:25  *** molly has quit IRC
 32020-02-25T01:30:17  <kanzure> in the taproot bip, non-malleability is a motivation: why? segwit solves this right? i like non-malleability of course.
 42020-02-25T01:41:55  <aj> kanzure: wtxid malleability is still nice to avoid, as is having different sizes of witness data which might let people malleate your fee rate over p2p?
 52020-02-25T01:48:13  <sipa> also tx propagation is hurt by malleability, which indirectly contributes to block propagation in compact blocks & co
 62020-02-25T02:00:00  <kanzure> thank you. we're in a socratic seminar at the moment :).
 72020-02-25T02:00:30  <aj> oh, then the answer should have been "why do you think non-malleability would be a motivation?" ?
 82020-02-25T02:01:45  <kanzure> well really it turned into "we're reading bip-340 out loud and watching adiabat explain schnorr signatures on youtube"
 92020-02-25T02:04:32  <kanzure> for tagged hashes, in what situation is nonce reuse expected? like low-entropy nonces ..?
102020-02-25T02:04:59  <aj> do you mean tag reuse?
112020-02-25T02:05:25  <kanzure> "For example, without tagged hashing a BIP340 signature could also be valid for a signature scheme where the only difference is that the arguments to the hash function are reordered. Worse, if the BIP340 nonce derivation function was copied or independently created, then the nonce could be accidentally reused in the other scheme leaking the secret key."
122020-02-25T02:05:36  <kanzure> this would only be true for low-entropy nonces right?
132020-02-25T02:05:53  <aj> or if the nonce is deterministic
142020-02-25T02:06:07  <kanzure> oh i see, i can see ways that deterministic nonces would conflict.
152020-02-25T02:23:33  <ghost43> Let's say I want an M of N multisig policy. Due to restrictions with interactivity, let's say I don't want to use musig as part of the scheme. I could either have a single tapleaf testing the M-of-N using OP_CHECKSIGADD, or I could create N choose M tapleaves each with an M-of-M using OP_CHECKSIGADD. If M,N are small, say 3-of-5, both are equally workable. The many tapleaf case looks more desirable due to having to reveal less details
162020-02-25T02:23:33  <ghost43> about the policy on chain. Looking at the sighash in the bips, do I understand it correctly that with the combinatorial setup each signer commits to the other actual signers, i.e. the first signer would have to choose who the other M-1 signers are going to be?
172020-02-25T02:29:40  <kanzure> grammatical bug in "this prevents lying to offline signing devices about output being spent" in bip341
182020-02-25T03:25:36  *** luke-jr has quit IRC
192020-02-25T03:28:30  *** luke-jr has joined ##taproot-bip-review
202020-02-25T03:52:03  *** CubicEarth has quit IRC
212020-02-25T03:53:25  *** CubicEarth has joined ##taproot-bip-review
222020-02-25T04:21:09  <kanzure> https://diyhpl.us/wiki/transcripts/austin-bitcoin-developers/2020-02-24-socratic-seminar-6/
232020-02-25T04:23:16  <aj> ghost43: (i find k-of-n less confusing fwiw)
242020-02-25T04:24:54  <aj> ghost43: yes, each signature commits to the tapscript, so if you have a different tapscript for each group (ie ABC, ABD, ABE, BCD, BCE, CDE) then you have to decide in advance which of those you're going to do
252020-02-25T04:26:58  <aj> ghost: you do ABC with "A CHECKSIGVERIFY B CHECKSIGVERIFY C CHECKSIG" presumably, no checksigadds. if you did ABCDE,k=3 with "A CHECKSIG {B,C,D,E CHECKSIGADD} 3 EQUAL" there's only one script and you're fine. if you're not doing musig, i think that's cheaper too?
262020-02-25T04:37:03  *** sipa has quit IRC
272020-02-25T04:43:03  *** sipa has joined ##taproot-bip-review
282020-02-25T07:57:06  *** jonatack has quit IRC
292020-02-25T08:32:52  *** jonatack has joined ##taproot-bip-review
302020-02-25T09:01:01  *** jonatack has quit IRC
312020-02-25T09:02:51  *** mol has quit IRC
322020-02-25T09:56:36  *** jonatack has joined ##taproot-bip-review
332020-02-25T11:06:43  <ghost43> aj: oh indeed, no need for checksigadd for n of n.
342020-02-25T11:07:44  <ghost43> I wonder what the reason is for including the tapleaf in the sighash. I mean, at least with SIGHASH_ALL, I can't see what harm it could do to replace which leaf the sig is for.
352020-02-25T13:02:11  *** mol has joined ##taproot-bip-review
362020-02-25T13:20:59  *** belcher has joined ##taproot-bip-review
372020-02-25T13:44:01  <ghost43> I would argue that if you don't want the sig used for a different leaf, you should not reuse the pubkey between the leaves. it's the user's responsibility then. e.g. there might be a leaf with some timelock acting as a backout policy, and another leaf with a multisig. you might want to presign only the backout leaf. in that case, use different pubkeys. it's too restrictive to also sign which leaf you want to be executed imho. but maybe
382020-02-25T13:44:01  <ghost43> I am missing something
392020-02-25T14:20:53  <pinheadmz> kanzure: re: malleability (and someone correct me if I'm wrong) but I think Tapscript also consensus-enforces a few rules that were formerly just standardness rules, like NULLFAIL and MINIMALIF
402020-02-25T15:26:10  *** pinheadmz has quit IRC
412020-02-25T15:26:35  *** pinheadmz has joined ##taproot-bip-review
422020-02-25T15:39:41  <sipa> ghost43: malleability
432020-02-25T15:40:13  <sipa> not being able to rebind a signature created for one script to the same key used in another branch
442020-02-25T15:41:13  <sipa> as it's reasonable to reuse keys across scripts
452020-02-25T15:41:40  <ghost43> well okay, but I am arguing for malleability here; I guess. I saying exactly that in some cases you might not care which script get executed, only that some UTXO get spent to some particular new outputs
462020-02-25T15:41:57  <ghost43> like the above mentioned k of n multisig example
472020-02-25T15:42:39  <ghost43> but I get it that one could argue either way
482020-02-25T15:44:26  <ghost43> only entities that know the other tapleaves could malleate, which most often are only the actual participants
492020-02-25T15:45:27  <ghost43> I guess this can be swept under the rug with "maybe with another sighash flag sometime in the future" (aka "go away") :)
502020-02-25T15:46:16  <sipa> i don't think the malleability itself you can get from that is a useful feature... but the effifiency optimizations may be (so that you don't need one signature peotocol instance per potential branch)
512020-02-25T15:47:12  <ghost43> well it's definitely a useful feature not to have to pre-select who the other signers will be as part of a multisig if you are the first signer
522020-02-25T15:48:00  <ghost43> in fact that is how current CHECKMULTISIG works, i.e. doing combinatorial tapleaves with k-of-k multisig to hide unused pubkeys in a generic k-of-n does come at a cost
532020-02-25T15:53:21  <sipa> yup, and within a script that property is maintained
542020-02-25T16:57:20  *** mol has quit IRC
552020-02-25T18:43:43  *** ghost43 has quit IRC
562020-02-25T18:44:01  *** ghost43 has joined ##taproot-bip-review
572020-02-25T19:14:27  *** ghost43 has quit IRC
582020-02-25T19:15:12  *** ghost43 has joined ##taproot-bip-review
592020-02-25T19:57:14  *** jonatack has quit IRC
602020-02-25T22:16:15  *** belcher has quit IRC