--- Log opened Fri Oct 18 00:00:38 2019
09:04 -!- digi_james [sid281632@gateway/web/irccloud.com/x-hcjqmmywqumzjqio] has joined #bitmetas
09:11 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
09:11 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitmetas
13:40  * aj waves
13:40 < sipa> aj: neutral... just observing that it's probably similar to what you'd come up with as a lecture series
13:42 < aj> 'k. think that makes sense to me, the goal of both is understanding the material (whether so you can pass a test, or intelligently criticise it)
17:49 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 265 seconds]
17:55 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitmetas
18:39 < sipa> aj: i wonder if there isn't a more top-down approach to structuring review than step-by-step
18:46 < sipa> for example (1) are the goals desirable (e.g. why do we want indistinguishable cooperative spends, why care about extensibility, why support batch verify, why drop P2SH, why replace sigop limit)   (2) discuss the design decisions that follow (taproot/merkle properties, replacing CMS with CSA, OP_SUCCESSx, ratio limit, ...)   (3) discuss the implications for users (different ways of doing multisig based on 
18:46 < sipa> setup and/or signing interactivity...
18:46 < sipa> availability, complexity of 32-byte keys, ...)  (4) the actual details (bit packing stuff here and there, lexicographic sorted merkle tree, leaf versions, ...)
18:47 < sipa> i'm not sure that if you start by discussing just schnorr people get the picture for why it is useful in the first place
18:48 < sipa> on the other hand, that approach is maybe actually more appropriate for a lecture... for a review session people probably know the material up front (hopefully...)
20:44 < aj> "discuss the implications for users ... availability" -- i don't know what that means?
20:49 < aj> sipa: i think a lot of the "are these goals desirable" is already covered in the rationale in the bips, and i tend to think it's a bit hard to really think about those without going into the details -- all the goals are desirable until you get up to the tradeoffs or implementation costs, but you don't know what those are without knowing the details
20:50 < aj> https://docs.google.com/document/d/1Nr0UlEGK5bVEZEd8Wi2Anxld1XqW69v4wc3a9d86k7A/edit?usp=sharing  # google doc with the above more or less
20:55 < aj> i didn't like the "start discussing just schnorr" either, but it's hard to talk about taproot without talking about schnorr, and hard to look at the details of the taproot bip without knowing at least the basic details of the schnorr bip. but maybe just "pubkeys are 32 bytes, and schnorr lets you do multisig with a single combined pubkey and combined signature" is all the background you actually need?
20:56 < sipa> aj: yeah, it probably os
20:56 < sipa> *is
20:58 < aj> bip-taproot already describes the latter "as they permit <a>key aggregation</a>: ..." so that part's probably fine
20:59 < aj> and "Let q be the 32-byte array .. which represents a public key according to bip-schnorr." is probably fine for the first part
21:01 < aj> so maybe 1) taproot, 2) tapscript/mast, 3) schnorr, 4) sig details and limits, 5) adv schnorr, 6) upgrades could work
21:16 < aj> the other things i was thinking of is that just splitting up the BIPs means you can be pretty confident you've actually checked it all; and i was thinking it'd be good to try to let people look at it with relatively fresh eyes without leading them down the same paths we took when designing it
21:20 < sipa> i think starting with taproot makes sense
21:26 < aj> i put "Intro & Taproot" first and added "What questions to ask while reviewing PRs?" with "goals/design/tradeoffs/user impact/details fit together" as suggestions fwiw
21:32 < sipa> do you expect mostly review of the bips, or of the reference code?
21:33 < sipa> i just pushed a new taproot branch btw; with a few extra moveonly commits it should be a lot easier to review now
21:46 < aj> i'd guess mostly the bips, but a few people will look at the python and bitcoin code, if anyone looks at the secp code i'll be impressed i guess
--- Log closed Sat Oct 19 00:00:38 2019