maaku> moli: also we don't see the list of rejected proposals (which I'm not privy to either)
<maaku> i've seen many "why wasn't there a talk on X?" questions, for which the answer is often "because there wasn't a proposal on X by anyone qualified to speak on it"
<maaku> although some good talks were also rejected due to lack of space.
<moli> maaku, i understand, maybe it will be at the next scaling conference? i hope so
<maaku> that is likely. I don't think that there has been sufficient work done on MAST approaches
<maaku> e.g. both segwit and schnorr have been talked about, iterated on, prototyped, and deployed on test networks before a solid proposal was made and talked about at Scaling Bitcoin
<maaku> we're not quite to that level with MAST, although I hope that we will be soon.
<moli> thanks, maaku, good to know, now we can pressure whoever that came up with the MAST idea please hurry up... lol... jk
<maaku> That would be roconnor, many years ago.
<maaku> But there's been LOTS of people working on it since.
<maaku> Which is the problem -- we're in the phase of everyone having their own favored approach and not enough data to fully determine which one is better
<molz> maaku, what are the deficiencies of BIP114 MAST ?
<maaku> molz: I think BIP 114 is overly complicated and layer violating
<maaku> a better approach to accomplish the same thing would be to have OP_HASHTREEVERIFY and OP_EVAL as separate opcodes
<maaku> imho
<maaku> (OP_EVAL is BIP 17, there isn't yet a BIP for a hashtreeverify opcode, that I know of)
<maaku> if you want to add MAST to bitcoin script, that's a reasonable approach
<moli> hm isn't OP_EVAL not good to use?
<maaku> moli: there is absolutely nothing wrong with OP_EVAL. it was killed as a matter of needless and excessive conservatism that proved in the end to be of bitcoin's detriment (imho)
<maaku> but I think an even better idea is to replace script entirely, fixing all of its deficiencies and also just happening to support MAST, tree keys, etc.
<maaku> roconnor is currently working on something like this within blockstream, to be made public after more work is done to implement it and get peer review
<maaku> some history: basically the initial implementation of BIP 17 had a huge security vulnerability, and because there was pressure to release something NOW the developers went with BIP 16, P2SH
<maaku> but in hindsight BIP 16 has some severe limitations (like the 520 byte push limitation for the redeem script) and BIP 17 would have supported MAST out of the box (because you could put an OP_EVAL within an IF-ELSE block)
<maaku> so I think objectively BIP 16 was the wrong choice, and this is an argument for waiting to make consensus changes until there is agreement on both the idea AND the basic approach
<moli> interesting... thanks, maaku
<gmaxwell> initial implementation of BIP 12, not 17.
<maaku> gmaxwell: thank you for the correction
<maaku> s/BIP 17/ BIP 12/ in the above
<jl2012> maaku: would you mind elaborate the layer violating of BIP114?
<maaku> jl2012: I think I did above. BIP 114 specifies consensus logic for MAST validation. I would prefer that this was done in script, which I think only requires an OpHashTreeVerify and OpEval
<maaku> Both of which are really simple (e.g. a few 10's of lines of code)
<jl2012> maaku: if you say 10's of lines, it's similar to BIP114. I'm open to other design, but my rationale is to keep static analysis possible. Otherwise, we may face the same trouble as the failed ETH softfork
<nsh> when does static analysis become impossible?
<nsh> have we mapped the chomsky descriptive complexity fine-structure yet?
<jl2012> nsh: if we had OP_CAT, OP_SUBSTR etc with OP_EVAL, static analysis is totally impossible
<nsh> sure
<nsh> well, modulo other constraints
<nsh> but there's a rich landscape before you fall off the decidability cliff :)
<jl2012> that means we need completely new way to count nSigOps, for example
<btcdrak> this convo should be in #bitcoin-dev  or wizards so it gets logged