Logs of the group discussion #6 of the Bitcoin Taproot BIP review - Week 1

taproot_review_week1

18:58 < Lexyon__> Well, hello everyone :)
19:00 <@sosthene> Hi
19:01 < waxwing> hi
19:01 <@sosthene> Ed said he would be here in an email
19:02 < waxwing> what are we going off, this? this right: https://github.com/ajtowns/taproot-review/blob/master/week-1.md
19:02 <@sosthene> yes
19:03 <@sosthene> I think since there's so many resources, we'd better focus on the BIP for now
19:03 < waxwing> right https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
19:03 <@sosthene> at least it feels like that's what everyone has been doing this week
19:03 < waxwing> do we want to answer each of the bullet point questions in the former?
19:04 <@sosthene> We can begin doing that
19:04 <@sosthene> and see what comes out of it
19:04 < Lexyon__> agred
19:04 < waxwing> "Do the goals make sense?". I had a bit of an issue with this question, as per the notes i linked earlier. link again:
19:04 < waxwing> https://0bin.net/paste/O8pgLKiV76oEoItM#yplmKf+KJZHvdWJZVF9lKtfbfzQ77lUWnbNxTjzntde
19:04 < Lexyon__> i think you are right about the goals
19:04 <@sosthene> yes I was reading it, and we discussed it earlier with Lexyon__ 
19:05 <@sosthene> we basically agree I think
19:05 < waxwing> right. so what do you think the goal of the BIP (or *taproot*) actually is?
19:06 <@sosthene> well, precisely we're not so sure after reading the BIP, I think that's an issue :)
19:07 < Lexyon__> privacy, efficiency, reducing ressources needed for nodes (computing operation & scripts), space saving, efficiency for M-of-N policies, 
19:07 < Lexyon__> but yeah, i feel a bit confused
19:07 <@sosthene> the "motivation" part in the BIP just hint at other BIP but doesn't really answer the question
19:08 < waxwing> yeah i'm ok with that list, perhaps you could say also 'leveraging more the advantage of Schnorr linearity+signature aggregatability'
19:08 < waxwing> but i think yeah that's fine. we could suggest also adding a more explicit reference to gmaxwell's earlier summary on key points (though it's linked): https://www.mail-archive.com/[email protected]/msg06673.html
19:08 < waxwing> in particular he defines what he calls the 'taproot assumption'.
19:09 < Lexyon__> yes, that was on my notes (it's not clear where this assumption come from in the BIP)
19:09 < waxwing> and also maybe even refer back to pay-to-contract-hash, and explicitly write it as Q = P + H(P||S)G or similar. but i think that's just debatable so maybe not, dunno.
19:10 < Lexyon__> Can't answer about that, it's out of my abilities scope
19:10 < waxwing> (hmm i think maybe someone was suggesting using a meeting bot ... but, we have this logged anyway)
19:10 < waxwing> well we can just move on to the other Qs maybe?
19:11 < Lexyon__> Do the design decisions follow from the goals?
19:11 < waxwing> yeah it's pretty broad :)
19:12 < Lexyon__> It seems so, but i am not able to say this is the better way to achieve these goals
19:12 <@sosthene> that one is a bit though
19:12 < Lexyon__> and, as the goals are not really explicit, it not make things easier
19:13 < waxwing> yeah. i'm going with the idea that the introduction paragraph of 'Design' is really the goal.
19:13 < Lexyon__> I'm not sure if it goes in this question, but i have a question about #signature validation rules
19:14 < Lexyon__> https://www.irccloud.com/pastebin/G7LxYPTy/
19:14 < Lexyon__> what happens if not valid signature according to bip-schnorr and hash_type =/0x00 ?
19:14 < waxwing> =/ meaning not equal?
19:14 < Lexyon__> yes
19:15 < Lexyon__> because there is an 'otherwise the signature is valid' just after
19:16 < waxwing> oh it's because of the logic of how it's written
19:16 <@sosthene> the otherwise is for all the "if" above
19:16 < waxwing> third bullet point inside second bullet point, isn't it?
19:16 <@sosthene> it's like "if none of the above apply, then signature is valid"
19:17 < waxwing> if *not* valid signature, and hash type is not 0x00, it's the third bullet point of the second bullet point, and it fails.
19:18 < Lexyon__> well, this scenario was not included, but i don't know if it's worth including
19:18 < waxwing> sosthene, pretty sure he means that case, where it's got a hash type, so 65 bytes not 64, but the signature itself is invalid.
19:19 < waxwing> our curriculum for this week was supposed to exclude signature validation rules, technically. i mean, i don't actually mind :) just for clarity.
19:19 <@sosthene> sure, but I don't mind either
19:20 < Lexyon__> i should just specify that i have an intermediate level and i don't code 
19:20 <@sosthene> hash_type = 0x00 is SIGHASH_ALL?
19:21 < waxwing> Lexyon__, that's not a problem, don't worry. we won't talk about the code then.
19:22 < waxwing> sosthene, oh good question, i don't know now .. because it seems they're saying the default is 0x00 but sighash_all currently is 0x01
19:22 <@sosthene> oh yes it is
19:23 <@sosthene> so 0x00 is basically no hash_type?
19:24 < waxwing> i don't get it. we will doubtless cover this in future weeks :)
19:24 < Lexyon__> it seems that the issue with 0x00 is that you can bring maleability between 64 bytes and 65 bytes signatures
19:24 < waxwing> it seems to say that old sighash types are preserved, but they are basically 1,2,3 and 0x80+1,2,3
19:25 <@sosthene> yes, I didn't notice that but now I'm confused too
19:25 <@sosthene> ok, I have another question that is maybe a step back, but anyway
19:25 < waxwing> Lexyon__, yes, not sure of exact import, but basically they're going for "0x00 is default" and therefore it's better to *not allow* you to be explicit, and add it, to avoid malleability (even though segwit doesn't allow malleability in the most normal sense)
19:26 <@sosthene> the BIP seems to take as self-evident that we will have Schnorr and Taproot simultaneously, but I'm not too sure to understand why we could not have Schnorr implemented before Taproot
19:26 < Lexyon__> agreed
19:27 < waxwing> sosthene, i think it's a great and valid question, i have been wondering it a bit. it would definitely be possible.
19:27 < waxwing> my expectation is that it would be undesirable to add taproot after, since it would need another version of a scriptPubKey distinct from a 'plain Schnorr' scriptPubKey type.
19:28 < waxwing> and that would very much work against taproot's advantage - that ordinary single key spending is indistinguishable from 'special' spending with script conditions.
19:28 < waxwing> but independent of my answer, we could ask this to pieter et al in terms of, it would be nice to write a sentence in the BIP explaining why that path wasn't chosen.
19:29 < Lexyon__> well what is the (ethic?) limit to the number of different scriptpubkey types ?
19:29 <@sosthene> yes indeed
19:29 < Lexyon__> and is there a technical limit or the issue is more about clarity for users ?
19:29 < waxwing> Lexyon__, as i was mentioning in my notes from earlier, we already have many distinct types, and we are getting more. there isn't really a limit, but i think we should be aiming to reduce, not add.
19:30 < waxwing> the big advantage of taproot is that it allows an extremely wide variety of different *output types* to look the same (complex scripts and simple spends).
19:30 < Lexyon__> yep, i think i share your point, as i used to deal with a lot of newcommers that get easily lost with all that
19:30 <@sosthene> I didn't read the Schnorr BIP, but what do you mean by ScriptPubkey type?
19:31 <@sosthene> like a Segwit version?
19:31 < waxwing> so basically any bitcoin output is an amount, and a scriptPubKey
19:31 < waxwing> not only segwit, the term scriptPubKey is from before segwit (from the start)
19:32 < waxwing> so currently we have: pay-to-pubkey (old, unused), pay-to-pubkey-hash (p2pkh), pay-to-scripthash (p2sh, BIP16), p2wpkh, p2wsh (witness equivalents of previous two) and p2sh-wrapped versions: p2sh-p2wpkh, p2sh-p2wsh.
19:33 < waxwing> each one has a standard encoding defining how a future spend of that coin can work.
19:33 <@sosthene> and implementing Taproot before Schnorr would save us the trouble of having a "P2Schnorr" type?
19:33 < waxwing> the last 4 (all the ones with "w") are segwit v0, which is the only version of segwit we currently have.
19:33 < waxwing> sosthene, well depends how you look at it, but you could say that, yeah. if we do schnorr now and taproot later, we'll need a P2Schnorr, indeed.
19:34 <@sosthene> ok that's a point
19:34 < waxwing> but my main point was not the complexity, it was that if we have p2schnorr and p2taproot then taproot won't share the anonymity set of the p2schnorr outputs
19:34 < waxwing> i mean the complexity matters too :)
19:35 < waxwing> maybe we should think a little bit about the remaining questions in that list. any thoughts about those?
19:36 <@sosthene> mmmhhh does it mean that eventually all bitcoin output would become P2TR? 
19:36 < Lexyon__> https://www.irccloud.com/pastebin/5EsRHdOL/
19:36 <@sosthene> yes you're right
19:36 < waxwing> 'how will this affect people'. pretty vague but anyway :)
19:36 < Lexyon__> i have several points to present also
19:36 < waxwing> Lexyon__, again you're asking about stuff that wasn't in this week's goals :) that's the transaction digest algorithm right.
19:36 < waxwing> i haven't looked into it yet sorry.
19:37 < Lexyon__> ok, nevermind we will talk about that later :)
19:37 < waxwing> feel free to go ahead if you have other points.
19:37 <@sosthene> waxwing I think you pretty much nailed it with "his is a big deal for advanced usage, not so much for every day usage. This is perhaps a concern (over adoption, I mean).
19:37 < Lexyon__> https://www.irccloud.com/pastebin/zjDP5mLZ/
19:38 < waxwing> well maybe, i dunno. i could imagine like, people have a LN wallet and it uses p2taproot by default, then it could work well like that.
19:38 < Lexyon__> what does 'less' mean in this context ?
19:39 < waxwing> you can think of hash values as literally integers (256 bits long in this case)
19:40 < waxwing> so 'less' is well defined there. at least i'm pretty sure that's what's meant, i would have to read carefully, but again, this was explicitly outside the scope of this week's meeting :)
19:41 < waxwing> "if right_h < left_h:" <- that line in the python code is comparing hash values, which are integers.
19:41 < Lexyon__> ok :D, it's more clear for me now, thx
19:41 < Lexyon__> About people who use bitcoin, i have a point
19:43 < Lexyon__> This is a huge change in the protocol, even if kind of discreet. A lot of people will seek  information about Taproot, and it is really complex to process.
19:43 < Lexyon__>  This is a huge issue IMHO, as Taproot is changing some consensus rules. And, when consensus rules are debated, every active user should get involved. In the present situation, it is really hard to make its own mind, as the subject is highly complex and the available content either too simplistic or far too technically advanced.
19:43 < waxwing> (btw it'd be better to just paste in comments here than use links i think, so the meeting logs have the text.)
19:43 < waxwing> oh ok, you did
19:43 < Lexyon__> this is probably not the point of the meeting either
19:43 < waxwing> that's an interesting point, because it is complex.
19:44 < waxwing> no i think it is,really. it's just hard to answer.
19:44 < Lexyon__> but, it seems this issue will just grow as the BIPs bring more abstraction
19:44 < waxwing> first it being a new segwit version means it's very uncomplicated as a soft fork, in terms of implementation.
19:44 <@sosthene> I can totally relate to that
19:45 < waxwing> but otoh the usage of the new scheme is i agree a really big deal because it's a lot more sophisticated idea, even than segwit.
19:45 < Lexyon__> and, i came to wonder how protocol will evolve in the future years. Will we end trusting a few experts ? Will it become even more political?
19:45 < waxwing> and most people did *not* understand segwit, like, at all. lol.
19:45 < waxwing> well Lexyon__ re trusting experts, i'd counter with: basically 0% of users understand how bitcoin works now, if you mean how the signing algorithm works.
19:45 <@sosthene> waxwing: I think I'm part of the people that did not understand Segwit indeed :D
19:46 < waxwing> but yeah these questions are tending to be more broad about issues, not so much about taproot any more. we should focus on that.
19:46 < waxwing> i think your valid point is that taproot itself is like, another layer of abstraction further than what we had already.
19:46 <@sosthene> I have one more point about what you just said, that it's part of Segwit versioning
19:46 < waxwing> a possible counterargument is: p2sh was also *very* abstract, not in a mathematical/crypto way, but it was like another layer of complexity in how you spend a coin.
19:47 < Lexyon__> true
19:47 <@sosthene> if I understood well, there's some bits that are dedicated to versioning of script in Taproot too
19:48 < Lexyon__> i understood the same
19:48 < Lexyon__> even if for now there is not a lot of ressources about that
19:49 <@sosthene> so does it mean that at some point we could just use segwit_V1 outputs, and if there are new ScriptPubkey Type they can be taken care of inside Taproot versioning itself?
19:49 <@sosthene> or am I mixing everything?
19:49 < waxwing> yeah i basically have the same question, but it *kinda* makes sense to me. taproot in particular seems to want to allow new script versions *within* it, i.e. within the merkle tree that gets put inside it. so it makes sense to have the tapleaf thing.
19:49 < waxwing> but you could still have entirely different segwit output versions, v2, v3 etc, completely outside taproot.
19:50 < waxwing> to be clear, i have NO idea if any of these future upgrade features are going to be used, but yeah, they seem to be there.
19:50 < Lexyon__> better plan now that lack the versionning later i guess
19:50 <@sosthene> yes of course we can't know anything about future features
19:51 < waxwing> oh your last point: hmm i don't think so. if you wanted a new scriptPubKey type using something different like a new signature algorithm, a new transaction digest, or some new crypto entirely, it couldn't be segwit v1
19:51 <@sosthene> but yes as you saif Lexyon__ , better have a plan just in case
19:51 < Lexyon__> i have a last point, very small one : Why BIP schnorr is 2-clause BSD license, and BIP taproot is 3-clause BSD license?
19:51 < waxwing> it's easy to say that this will be hard for users somehow, but do we see any other positive/negative effect on users?
19:52 < waxwing> Lexyon__, no idea about the license. we can ask of course.
19:52 <@sosthene> on the positive side, if it can help building services that use complex multisig setup it could be a big win
19:53 <@sosthene> for long-term adoption
19:53 < Lexyon__> Well, i think it will allow huge entity to feel more confident about the storage of their funds, and that make it easier for them to step in
19:53 < waxwing> so let's say someone needs a 1 of 100 multisig.. can they do it here? what if it's 99 of 100?
19:54 <@sosthene> Not sure about the consensus limits on the number of ops in a script, but the cases you propose seem borderline
19:54 <@sosthene> ok I think I got it
19:55 < waxwing> well i guess the first question should have been: what about 100 of 100? :)
19:55 < Lexyon__> it seems that Schnorr agregation is linear for batch signature, with the R option
19:55 < waxwing> yes. schnorr, even without taproot (but also with it) handles this problem perfectly IF it's N of N. So 100 of 100 is absolutely fine, one signature needed on chain.
19:56 < waxwing> but 1 of 100 or 99 of 100 are different, afaik there is work on 'threshold' variations of Schnorr multisig but it's not done, but: we can use the merkle tree.
19:56 < waxwing> with 1 of 100 we still would only need 1 signature on chain, but we just need a short merkle proof included that the given key was one of the branches.
19:56 <@sosthene> yes but even if you're trying to make a 1 of 100, can't you just create 100 scripts, one for each spending key?
19:56 < waxwing> exactly, in the merkle tree.
19:56 <@sosthene> ok I think we're saying the same think now
19:57 <@sosthene> *thing
19:57 < waxwing> but 99 of 100, unless i missed something (quite likely), is a problem in that it would need 99 signatures.
19:57 < waxwing> what i haven't checked out is how the limits have changed (as you mentioned sosthene ) ... but just generally nobody wants to publish huge scripts anyway, even if it *is* possible.
19:58 <@sosthene> except if you create enough scripts with each possible combination of 99 keys
19:58 < waxwing> oh right. i *think* that works.
19:58 <@sosthene> but maybe it would be *too many* scripts
19:58 < waxwing> well no that's only 100 combiations :)
19:58 < waxwing> but in general, yes you can get combinatorial blowup (50 of 100 is huge)
19:58 <@sosthene> oh, true
19:59 < waxwing> but i am not the person for discussing this stuff, i've never really looked into it (MAST + taproot +musig + large, complex scripts)
19:59 < Lexyon__> well, miniscript should help a bit there 
20:00 < waxwing> right, i think so.
20:00 < waxwing> but the scaling limitations will remain, except it might remove stupid designs :)
20:00 <@sosthene> I think too, but I'm not totally sure how exactly (well I have an idea, but I need to give it more thought)
20:01 < waxwing> anyway it's obvious we're in a vastly better place with both MAST and musig removing a lot of extreme limits Bitcoin script used to have.
20:01 <@sosthene> obviously
20:01 < Lexyon__> this is why i thing the watchtowerstuff for huge and complex script is a nice feature : it's a kind of a safety net for unexpecting script validation
20:02 < Lexyon__> and they also bring some welcomed privacy :)
20:02  * waxwing makes a mental note to check on hash_type = 0x00
20:03 < waxwing> OK I know the hour is up but i have a question for you: could we have done taproot before Schnorr, i.e. with ECDSA?
20:03 <@sosthene> Someone asked on the main channel, and the answer was basically yes, but it wouldn't make that much sense
20:03 < Lexyon__> i would say that it could be possible to do something with some of the benefits of taproot, but schnorr is really what empowers it
20:04 <@sosthene> sorry I didn't log this part as it was very early in the channel, so I can't find the specific argument again
20:04 < waxwing> sosthene, oh but i wanted *your* answer :) i asked it on the main channel today, but i don't think anyone answered? it was supposed to be like a 'get you thinking' question :)
20:04 < waxwing> oh it was earlier, i see
20:05 < Lexyon__> if i had to chose between taproot-like on ECDSA and Schnorr, i think i'll pick schnorr
20:05 < waxwing> Lexyon__, yeah that seems like a good answer, and i think you're right.
20:05 <@sosthene> ok didn't see it. As for me I guess the lack of Schnorr linearity feature in ECDSA would be very annoying, so it might not be impossible, but more complicated and maybe with different trade offs
20:05 < waxwing> Lexyon__, i'm curious, if i write Q = P + H(P||S)G for taproot, does that make sense to you?
20:06 < waxwing> yeah seems like everyone here gets it. makes sense to me.
20:07 < Lexyon__> i'll say that Q is P plus hash(concatenateP/S)*generator point, but clearly i lack hindsight and time to answer you properly fast
20:07 < Lexyon__> i'll think about that
20:08 < waxwing> Lexyon__, right. it's clear everyone understands the basics here :)
20:09 < Lexyon__> well, thank you for your time, that was really instructive !
20:09 <@sosthene> P is a public key, if you take the hash of it and concatenate it with the script you want to commit too, and then multiply by G, you get another Point in the curve
20:09 < waxwing> yeah
20:09 < waxwing> right i guess we should wrap up, agreed, is there anything specific we should do now?
20:09 < Lexyon__> but, what is the finallity ?
20:09 <@sosthene> yes I think we can stop here for today, thanks a lot waxwing and Lexyon__ 
20:10 <@sosthene> yes the conclusion :)
20:10 < waxwing> i see like 4 or 5 questions or points we've raised.
20:10 < waxwing> hash_type = 0x00 was one
20:10 < waxwing> taproot versions inside v1 was another
20:11 < waxwing> then the various comments/critiques about the Motivation section.
20:11 < waxwing> then possibly justification of taproot + schnorr vs just schnorr, then taproot later
20:12 <@sosthene> yes, maybe we could try to ask those questions on the main channel
20:12 < waxwing> also Q about the license, minor one, but doesn't hurt to ask
20:12 <@sosthene> I'm just not sure *when* we should do it, as I think next week Q&A will be devoted to next week topic
20:13 < waxwing> yeah. i mean arguably we already have a record of our questions and comments, logged here.
20:14 < Lexyon__> it's slightly off topic, but to whom i should ask for being added on the mailing list ?
20:14 <@sosthene> which one?
20:14 < Lexyon__> the one about taproot review :)
20:14 < waxwing> you had another good question earlier sosthene "<sosthene> wrt to the signature Hashing algorithm improvement: isn't it something that could be handled in another proposal? What's the rationale for including it with Taproot?"
20:14 <@sosthene> oh yes forgot this one
20:15 <@sosthene> thanks!
20:15 <@sosthene> Lexyon__: each group is communicating by email, so I can add you in our group exchanges
20:16 < Lexyon__> 👍
20:16 <@sosthene> and maybe we will get email from the organizers, I can forward it to you
20:16 <@sosthene> don't know if there's anything else to do
20:17 < waxwing> thanks
20:17 <@sosthene> I have one last question before we leave: what is your main take away of this first week?
20:18 < waxwing> i don't know
20:18 < waxwing> motivate the bip better? :)
20:19 <@sosthene> I guess for me, it's that we really need more accessible explanation of Taproot
20:19 <@sosthene> yes I guess that's one thing that bother me the most
20:20 < Lexyon__> feel that too
20:20 <@sosthene> I like to understand why we do something exactly, and I feel that it's not the case yet with this proposal
20:21 < waxwing> well that's motivation. but understanding how it works is another thing.
20:21 <@sosthene> yes
20:22 < waxwing> i guess it's really three things: understand why you'd want to do it (what's the advantage), understand how it achieves it (the mechanism), understand why it isn't dangerous (the security)
20:22 <@sosthene> yes, and maybe what are the trade-offs, even if it's more or less implicit
20:23 <@sosthene> Great, many many thanks to both of you!
20:23 < Lexyon__> Yes, that was great :)
20:24 < Lexyon__> next time, i'll try to stay in the week topic 😅
20:24 <@sosthene> I feel like at the bottom of a mountain now, but very excited to try my way to the top
20:24 <@sosthene> it's okay Lexyon__ ;)
20:25 < Lexyon__> meh, just zoom out
20:25 <@sosthene> well, should we say goodbye now?
20:25 < Lexyon__> and watch the path you already walked
20:25 < Lexyon__> you're in the middle of the mountain now :D
20:25 <@sosthene> I'll try to sum up what we said this weekedn
20:26 <@sosthene> Bye!
20:26 < Lexyon__> bye!
20:26 < waxwing> bye :)