--- Log opened Tue Nov 05 11:37:53 2019 11:37 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined ##taproot-bip-review 11:37 -!- Irssi: ##taproot-bip-review: Total of 69 nicks [2 ops, 0 halfops, 0 voices, 67 normal] 11:37 < sipa> gmaxwell: i believe not 11:37 -!- Irssi: Join to ##taproot-bip-review was synced in 1 secs 11:38 < gmaxwell> K. didn't think so. 11:38 < sipa> there is one that uses the generic group model on the curve + collision resistance on the hash function 11:38 < sipa> and one that uses DLP on the curve + ROM on the hash function 11:38 < sanket1729> I think the question might be better phrased as "What additional assumptions do we have that we did not have in bitcoin previously?" 11:38 < sipa> but not one with just DLP on the curve + collision resistance on the hash function 11:38 < sipa> sanket1729: that is of course a hard question, as we don't actually know all the assumptions that bitcoin needs for security 11:39 < kabaum> Q from group 5 (8/8): "Design": I'm not sure what strong security assumption actually means? Are there "weak" security assumptions? 11:40 < jnewbery> I think it's quite a vague sentence "can be improved by deviating from the optimal tree". I think wallet implementers could as easily fingerprint themselves by trying to do something clever that deviates from the optimal tree. 11:40 < sipa> maybe it should just say "specific security assumptions" ? 11:40 < gmaxwell> sipa: I do believe that bip-taproot isn't intended to add any additional strong assumptions that we don't already have. 11:40 < andytoshi> jnewbery: if the full tree is never revealed that's not obvious to me 11:40 < andytoshi> you may even get better fingerprint resistance by using non-optimal trees 11:40 < sipa> gmaxwell: right, i agree! but being specific about is hard 11:41 < andytoshi> (if your usual spending cases only use low-depth paths it may look like you have fewer paths than you do) 11:41 < instagibbs> kabaum, assumptions can be considered stronger and weaker yes, but it might be a judgment call 11:41 -!- moneyball changed the topic of ##taproot-bip-review to: Discussion about the Taproot BIP Reviews. Please sign up by Oct 30th: https://forms.gle/iiPaphTcYC5AZZKC8 ; more information: https://github.com/ajtowns/taproot-review; logs http://www.erisian.com.au/meetbot/taproot-bip-review/2019 11:41 < andytoshi> well there are things like "P ≠ NP" that you could consider to be a "weak" security assumption 11:41 < sipa> but we're not adding any of those 11:41 < jnewbery> andytoshi: I think that's what the BIP says: use a suboptimal tree to get petter fingerprint resistence. It's just not obvious to me how useful that advice is. 11:42 < sipa> if your point is we should avoid non-actionable advice, i agree 11:42 < gmaxwell> jnewbery: I think it is extremely useful advice but it could be stated better. 11:42 < sipa> but if it's too vague to be non-actionable, maybe it should just be made more specific 11:43 < gmaxwell> jnewbery: in particular, if you can adjust your tree so that common cases look just like common thresholds (like 2 of 3) then you probably get a large increase in indistinguishablity. 11:43 < hebasto> sipa: bip draft states: Not adding any new strong security assumptions. maybe remove "strong"? 11:43 < gmaxwell> I think the text is vague in its advice in part because it doesn't know in advance what forms will be common. 11:44 < andytoshi> hebasto: i agree with that 11:44 < sipa> so devil's advocate... there is probably a set of weird assumptions under which bitcoin currently can be proven secure, and which are not sufficient to prove schnorr/taproot secure 11:44 < gmaxwell> Maybe it should instead explain the procedure someone should use to be more indistinguishable? (making your common spend paths look exactly like other common spend paths on the network, by arranging them to be at the same depths) 11:44 < jnewbery> Other good privacy advice would be make a 2-of-3 threshold the internal pubkey, rather than 3-of-3, if you think that 2-of-3 is more likely. But again, I don't think it's the BIP's place to enumerate all the ways to optimize privacy 11:44 < andytoshi> well you could enumerate all the parts of bitcoin, observe that "taproot is secure" is not listed 11:44 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Quit: Sleep mode] 11:45 < sipa> andytoshi: sure, you can come up with obvious models that are stupid but for which this is true 11:45 < gmaxwell> sipa: Strong assumption "Bitcoin is secure", clearly bip-taproot is not secure under that assumption. :P 11:45 < andytoshi> jnewbery: that advice comes with pretty tough tradeoffs (extra protocol complexity, data that needs to be stored offline and can't be recreated) 11:45 < andytoshi> lack of accountability 11:46 < sipa> my point is that if we want to state something about a comparison with existing assumptions, we should state those assumptions 11:46 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined ##taproot-bip-review 11:46 < andytoshi> "taproot requires only that DL is hard in secp256k1 and that sha256 is a RO" 11:46 < gmaxwell> jnewbery: actually for many users the top key should probably be a 2 of 2. :P 11:46 < jnewbery> andytoshi: sorry - I meant implemented as a 2-of-2 for the internal pubkey. But perhaps we're getting too into the weeds 11:46 < gmaxwell> jnewbery: (in the case of a 2 of 3 policy) 11:46 < andytoshi> jnewbery: ah! yep i see 11:46 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Client Quit] 11:47 < gmaxwell> jnewbery: I think that is, in fact good advice. It should probably never be a 3 of 3 for a 3 of 3 policy. 11:47 -!- ni638629 [~u749750@192.195.66.124] has quit [Remote host closed the connection] 11:48 < gmaxwell> sipa and I were having a more abstract discussion about that recently, that almost always you should bubble up a more restrictive policy higher in your tree. 11:48 < sipa> andytoshi: with tagged hashes it's probably possible to make it slightly weaker (like DL hard secp256k1 and the SHA256 *transform* is RO) 11:48 < andytoshi> ah good point. bitcoin has no tagged hashes today. 11:48 < andytoshi> (though it should :P) 11:48 < jnewbery> I have a more general question: what kind of input are you looking for on the bips right now? I have some minor style nits. Would they be welcome as PRs or would they be a distraction? 11:48 < hebasto> sipa: what is diff? 11:49 < sipa> hebasto: ? 11:49 < hebasto> sha256 is a RO vs SHA256 *transform* is R 11:49 < hebasto> *RO 11:49 < jonatack> Is someone compiling a todo action list from these sessions, or should we submit proposals in the Google forms? Assuming a bunch of issues/PRs may not be best here. 11:49 < andytoshi> jnewbery: if they're PRs rather than issues i think that'd be welcome. though it'd be good to consolidate them if they're small 11:49 < gmaxwell> jnewbery: if you look at recent changes to the bips, quite a few of them have been basically minor style nits. I'd say you should make them, just don't feel bad if you need to redo them again later after some other substantial changes were made. 11:50 <@aj> 10 minutes left, if anyone's been sitting on questions 11:50 < sipa> if there are suggestions you have that you think need more discussion, open an issue (or if it's a big design question, even an ML thread) 11:50 < sipa> hebasto: let me explain that after the meeting 11:50 < hebasto> sipa: ok 11:50 < sipa> at this point i'd like to avoid nits on the reference code 11:50 < ariard> about comparison with bip116 and bip114, it's next week? 11:51 < sipa> as i think getting the design fleshed out has priority, and at this point my reference branch should only function as clarification for the proposal itself 11:51 <@aj> ariard: yeah, the MAST stuff is script path spends, so that sounds right 11:52 < ariard> aj: thnks holding mine then 11:52 < sipa> are there any other questions/topics? 11:52 < digi_james> I find MAST confusing as its not really an abstract syntax tree, but that's fine :) 11:52 < jnewbery> Merklized alternative script tree, you mean? 11:52 <@aj> digi_james: "merklized alternative script tree" :) 11:52 < andytoshi> lol 11:52 < sipa> digi_james: note that bip-taproot never uses the name MAST (except when referring to an older proposal with that name) 11:53 < andytoshi> digi_james: you're welcome to use simplicity if you want an abstract syntax tree. it is not deployed anywhere but that's fine, it will take you years to get up to speed enoguh to use it anyway ;) 11:53 < digi_james> ha, sorry I thought it was abstract syntax tree all along 11:53 < andytoshi> i think it was, historically 11:53 < digi_james> right? 11:53 < sipa> digi_james: the name MAST comes from roconnor, and referred to what has now become simplicity 11:53 <@aj> yeah, it was IF ELSE ENDIF sort of 11:54 < sipa> what merkle branched script proposals used from that was not the abstract syntax tree part at all, just the merkle :) 11:54 < luke-jr> I thought it was jl 11:54 < sipa> oh, this was years earlier 11:54 < digi_james> Ok, so in that case the tree did encode syntax ... 11:54 < digi_james> Sorry - thanks for the history lesson :) 11:54 < instagibbs> russel -> jeremyrubin -> jl/maaku -> etc 11:54 < instagibbs> anyways not important... 11:55 < sipa> but in any case, i think the name MAST is wrong for what is included in bip-taproot, and it also doesn't use that name :) 11:56 < gmaxwell> just retcon the term to be a "merkelized arbritary script tree" 11:56 < sipa> 11:52:40 <@aj> digi_james: "merklized alternative script tree" :) 11:56 < andytoshi> merkleized arbitrary structure of things ;) 11:56 < ariard> but what bip-taproot doesn't hold as features compare to previous MAST proposals? 11:57 < ariard> on the high-level without getting into details 11:57 < andytoshi> ariard: ability to access the root (or other hashes) from within script is one 11:57 < sipa> ariard: there was an earlier proposal that supported multiple tree leaves simultaneously 11:57 < luke-jr> ariard: it's a merkle tree, but not of AST components 11:57 -!- pinheadmz [~matthewzi@185.217.69.139] has quit [Quit: pinheadmz] 11:57 < sipa> ariard: but there has never really been a concrete proposal that was called MAST that actually was a merkleized abstract syntax tree, apart from simplicity 11:57 < ariard> andtyoshi: recursively executing another tree committed in one of the key included in a script? 11:57 < sipa> (to the best of my knowledge) 11:58 < andytoshi> ariard: yeah 11:58 < andytoshi> so like, you can't (efficiently) use taproot to implement keytrees in some cases 11:58 < andytoshi> like if you want to check 3 keytrees in a row or something 11:58 < ariard> sipa: could we execute multiple tapscript with a future taproot upgrade ? 11:58 < digi_james> ariard: Thinking of it, that seems pretty cool. 11:58 < andytoshi> you can't just do OP_CHECKSIG OP_CHECKSIG etc 11:58 < ariard> like leaf A || leaf B || leaf D 11:59 < sipa> ariard: not in the same way; it can always be done using script instructions that add that functionality inside script 11:59 < andytoshi> well, the choice that taproot makes has the nice property that it minimizes design surface 11:59 < gmaxwell> andytoshi: or if you have a bag of keys and want to yank out multiple leaves. 11:59 < andytoshi> which makes consensus easier to get :) 11:59 < andytoshi> gmaxwell: ah yeah! 11:59 < ariard> sipa: not with some kind of tail-call semantic or weird pubkey type? 11:59 < sipa> so maybe this is the time to ask this: do people agree that the only semantical change discussed/considered in this meeting is the question of non-32-byte v1 segwit outlawed or not? 11:59 < ariard> a bit hacky 11:59 < digi_james> Hm, are there any advantages having multiple "roots" in a tapscript to vs just separate leafs? 12:00 < instagibbs> another question if time: what was the consideration for putting the leaf version in the control block vs allowing different leaves to be different versions? 12:00 < digi_james> In and AND construct, they have to be revealed anyhow, and with OR, may as well ad a tapleaf 12:00 < sipa> instagibbs: because it has literally zero downsides :) 12:00 < instagibbs> sipa, well, I can make some painfully obtuse design decisions otherwise ;) 12:01 < instagibbs> fair enough 12:01 < sipa> so specifically something that is not possible to do in the taproot structure is something like (1 of 2) AND (1 of 2) AND ... (repeats 64 times) ... (1 of 2) 12:01 < sipa> it is easily possible as a script 12:01 < gmaxwell> sipa: outlawed and or how it interacts with bech32. 12:01 < sipa> gmaxwell: yeah 12:01 < sipa> oh, bad example 12:01 < gmaxwell> digi_james: I might not have understood your question, but with AND's of policies the cost of putting them in the tree directly is a combinitoric blowup. 12:02 <@aj> sipa: officially overtime now, shall we stop meetbot logging and leave it for regular chatting? 12:02 < sipa> yeah 12:02 <@aj> #endmeeting 12:02 < lightningbot> Meeting ended Tue Nov 5 20:02:26 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:02 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.html 12:02 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.txt 12:02 < lightningbot> Log: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html 12:02 < sipa> something you can't do is (3 of 100) AND (3 of 100) AND (3 of 100) ... do this enough times, and you can expand it out to just leaves of one key each 12:02 < digi_james> gmaxwell: Right .. thank you 12:02 < jonatack> sipa: iirc there are 3 changes/todos in this discussion 12:02 <@moneyball> thank you to everyone for great participation! 12:02 < kabaum> sipa: from our point of view, yes, unless question 5/8 is considered semantics. 12:02 < kabaum> Thank you sooo much for your time, btc gurus. Love, group 5. 12:03 < sipa> but with a way to prove multiple branches simultaneously, it would be significantly simpler 12:03 <@aj> kabaum: great questions 12:03 < jonatack> kabaum: yes Q 5/8 and possibly s/Not adding any new strong security assumptions/Not adding any new security assumptions/ 12:03 < sipa> kabaum: what was 5/8 ? 12:03 < gmaxwell> digi_james: so for example a 10 of 1024 could theoretically be represented as a single tree of 10 of 10s... but it would be intractable to compute the pubkey! 12:03 < kabaum> Q from group 5 (5/8): In "Security": “Therefore, the privacy of key spends can be improved by deviating from the optimal tree determined by the probability distribution over the leaves.” We found this confusing, should it be script spends and not key spends? 12:03 < sipa> jonatack: right, i meant semantical discussions; not just improvements to the writeup 12:04 < sipa> kabaum: oh, agree 12:04 < sipa> we can improve the actual suggested approach there 12:04 < jonatack> all good 12:04 < gmaxwell> digi_james: but if you had a script that reused the same root 10 times, checked for duplication, then it would be a no brainer. And some of the earlier 'mast' proposals would have let you do this ... but with a pretty large implementation complexity / design analysis cost. 12:04 < bjarnem> gmaxwell: Could you briefly explain why "[..] you should bubble up a more restrictive policy higher in your tree"? 12:05 < sipa> hebasto: so specifically we know that SHA256 is not a random function, because for example it's vulnerable to length extension attacks. those are not relevant for our use case, but it is absolutely something that distinguishes it from a true random function 12:05 < sipa> hebasto: this is because SHA256 has a Merkle-Damgard structure, which is essentially applying a function called the compression function (i called it transform before, that was confusing) to an initial state and a block of data, and then again on the outcome and the next block of data, etc... 12:06 < digi_james> gmaxwell: Yeah. I guess I kinda like sipa's example with (1 of 2) AND (1 of 2) AND ... with the 1's being script commitments themselves. But perhaps that's a tapscript upgrade as previously mentioned. 12:06 < hebasto> sipa: thanks 12:06 < instagibbs> sipa, so any writeup of ... generalized... g'root(?) I just re-read all the e-mails linked in the bip and wanted to mull the idea fresh 12:06 < gmaxwell> bjarnem: er, thats really unclear of me, I should have said _less restrictive_. Like if your policy is 2_of_3 than the way we've often described taproot you would imagine putting a 3 of 3 at a top and then some scripts below to handle if all three parties aren't available. But it turns out for 2 of 3 you never want to do that. You want to put some 2 of 2 at the top, so you can use that 12:06 < gmaxwell> if they happen to be online. 12:06 < sipa> hebasto: i believe that we may be able to prove many security properties of schnorr and taproot using the assumption that just that compression function is sufficiently random, rather than relying on the whole function to be random 12:07 < instagibbs> yes you'd just do k-of-k leaves 12:07 < sipa> instagibbs: i do have a work in progress writeup, which i can link you to, but i'm not going to publish it now to avoid distracting the taproot discussion 12:07 < bjarnem> gmaxwell: ah, I see now, gotcha! 12:07 < hebasto> sipa: i thought SHA256 *transform* refers to tagged hash... 12:08 < instagibbs> sipa, interested, just throw it my way 12:08 -!- pglazman [~pglazman@205.209.24.227] has quit [Read error: Connection reset by peer] 12:09 < sipa> digi_james: so i guess the point is that taproot adds merkleization to the script structure, but not to script itself 12:10 < sipa> and there are certain policies that cannot be efficiently represented using what taproot permits, but would be possible with more flexible merkle branch verification opcodes in script 12:10 < sipa> though i believe those to be rare 12:10 < digi_james> sipa: Right - would be cool though :) 12:10 < bjarnem> thanks all for this nice session! see you next time! 12:11 -!- bjarnem [~bjarne@84.79.140.198] has left ##taproot-bip-review ["Leaving"] 12:12 < digi_james> I mean more efficient, like in the case you mentioned earlier (1 of 2) AND (1 of 2) AND ...). 12:12 < sipa> yes 12:12 < sipa> thank you for all the valuable input 12:13 < soju> thank you all! 12:13 < digi_james> Thank you, bb 12:14 < cdecker> Thanks for organizing ^^ 12:22 < kabaum> Thank you! 12:25 < xoyi-> Thanks, bye all! 12:28 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined ##taproot-bip-review 12:31 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-bip-review 12:32 -!- ajonas [sid385278@gateway/web/irccloud.com/x-roxvryzffjhjkyws] has joined ##taproot-bip-review 12:34 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer] 12:36 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack] 12:36 -!- xoyi- [~xoyi-@154.57.11.173] has quit [Ping timeout: 268 seconds] 12:38 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review 12:39 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Client Quit] 12:42 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review 12:43 -!- soju__ [~kwon@206.189.94.44] has joined ##taproot-bip-review 12:43 -!- soju__ is now known as soju_ 12:51 -!- Moller40_ [~mr@82.103.130.178] has joined ##taproot-bip-review 12:54 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review 12:55 -!- Moller40 [~mr@82.103.130.178] has quit [Ping timeout: 268 seconds] 13:01 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined ##taproot-bip-review 13:08 -!- soju [~soju@2601:640:8780:6d90:70c9:ccc7:933b:fc65] has quit [Remote host closed the connection] 13:21 < digi_james> Hm, regarding the “merklescriptverify” opcode, I fail to reproduce how it is more efficient. Using two very loose examples based on sipa’s previous comment: 13:21 < digi_james> (A|B|C|D) & (E|F|G|H) & (I|J|K|L) & (M|N|O|P) 13:21 < digi_james> With tapscript “merklescriptverify” opcodes: (2*4+1) * 32B = 9 * 32B proof (exact) 13:21 < digi_james> Without (using single pk tapleafs): 4*4*4*4 = 256 leafs, 8 * 32B proof (exact) 13:22 < sipa> digi_james: i'm talking about examples where the total number of combinations makes it intractible to completely expand out 13:22 < digi_james> (A|B|C|D|E) & (F|G|H|I|J) & (K|L|M|N|O) & (P|Q|R|S|T) 13:23 < sipa> if you can expand it out, thr taproot merkle tree is perfect 13:23 < digi_james> I must be missing something. Intuitively, the proof sizes grow O(log n) in both cases... 13:23 < sipa> but say there are 2^64 combinations, that'd not possoblr 13:23 < sipa> *that's not possible 13:25 < digi_james> Such as (1/2)&(1/2)&(1/2) .. x 64? 13:25 < sipa> yes, but that example isn't easy with merkle trees either 13:26 < sipa> but say (1 of 64) and (1 of 64) and (1 of 64) and ... 13:26 < digi_james> Hm ... 13:26 < sipa> until you have billions of combinations 13:27 < digi_james> so it would be "merklescriptverify" and "merklescriptverify" and ...etc. 13:27 < sipa> right 13:27 < sipa> it's even better if you want to do something like (4 of 64) and (4 of 64) and ... 13:28 < sipa> if your merkle verify opcode supports multiple branches simultaneously 13:28 < felixweis> i would also be interested in reading up on that g'root writeup 13:28 < digi_james> right ... 13:29 < digi_james> Is this part of graftroot? I am not sure. 13:29 < sipa> digi_james: no, completely unrelated 13:30 < nickler> g'root was mentioned on the mailing list? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html 13:30 < sipa> nickler: yes 13:30 < digi_james> nickler: Thanks a lot! 13:30 < sipa> digi_james: graftroot is very different from g'root, and both are unrelated to merkle branch verify 13:31 < felixweis> yes sorry for derailing 13:31 < felixweis> im just reading up on tapscript and the versioning 13:33 < felixweis> and was wondering if it's possible to sign off to delegate the spending on a future not yet defined tapscript version 13:33 < sipa> sure 13:33 < sipa> in theiry 13:33 < sipa> theory 13:34 < felixweis> to clarify, without sending it to a new ouput first 13:35 < sipa> once something graftroot exists, and it supports something like taproot's leaf versions, it very likely will also support signing over to spending with future leaf versions 13:35 < sipa> but that's a lot of hypotheticals 13:35 < digi_james> Hm... as I increase n for "<1/n> "merklescriptverify" and "merklescriptverify" and ...etc." the proof sizes grow logarithmically. But the same can be said about the inclusion proof for a merkle tree with n*n*n ..etc. tapleafs. I need to think about it a little more to see the efficiency gains. 13:40 < sipa> digi_james: again, i'm talking about a situation where you simply cannot expand it out 13:40 < sipa> as i said, if you can expand it, the taproot merkle tree is perfect 13:41 < sipa> so the choice is having just a single script that implements the entire policy (and thus includes all public keys), or multiple merkle verifys 13:42 < digi_james> Oh I see. Why would it not be possible to expand any script with OR's? 13:43 < sipa> because say if there are say 2^64 combinations it's just computationally intractable to compute the address 13:43 < sipa> let alone sign for it 14:00 < digi_james> Computing an address for a taproot output with depth 64 would be intractable? I think I understand you why signing would be a challenge - because wallet needs to figure out which of the 2^64 scripts to sign. Whereas with multiple "merklescriptverify"'s its much fewer combinations. I see merkle path limit is 128. 14:03 < sipa> digi_james: you simply cannot even iterate over 2^64 branches, let alone do 2^64 musig aggregations 14:03 < sipa> i mean, you can 14:03 < digi_james> right ... :) 14:04 < sipa> but there is some point where it simply goes from impractical to pointless 14:08 < digi_james> so this point is so far out, that it wouldn't be helpful to include a "merklescriptverify" opcode in tapscript? 14:08 < digi_james> "merkleverify" 14:09 < sipa> the reason it's not in there is that it can be done independently with no downside 14:10 < digi_james> another softfork? 14:11 < sipa> yes, if you like 14:11 < sipa> i mean, we have op_success for a reason, right 14:11 < digi_james> :) 14:12 < sipa> or not 14:12 < sipa> that's the point 14:12 < sipa> whether this is desirable should be an independent discussion 14:13 < sipa> and the nice thing is that doing it independently has no downside 14:17 -!- b10c [~Thunderbi@2001:16b8:2e72:7900:cc07:78de:5a5d:4009] has quit [Ping timeout: 245 seconds] 14:18 -!- pglazman [~pglazman@205.209.24.227] has joined ##taproot-bip-review 14:19 < digi_james> sipa: Thank you! 14:27 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined ##taproot-bip-review 14:35 < gmaxwell> digi_james: "Computing an address for a taproot output with depth 64" not at all, for a tree of size 2^64 like sipa was referring to, sure. 14:36 < gmaxwell> digi_james: but for example, if you have 64 options, each of which is much less likely to be used than the prior, you might make a tree of depth 64, and thats easy to compute. 14:36 < sipa> right, tree depth is roughly proportional to the log2(1/probability) of the least-probable script in your tree 14:37 < sipa> but what we're talking about here is tree *size*, not depth 14:40 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##taproot-bip-review 14:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 14:45 < digi_james> sipa: gmaxwell: yes right - thanks I was (wrongly) focusing on depth because of inclusion proof, but merkleverify alleviates complexity from size/leafcount 14:48 -!- Lexyon__ [uid402723@gateway/web/irccloud.com/x-ikrykvhetvoowiyc] has joined ##taproot-bip-review 14:48 < digi_james> or complexity resulting from (very large) option count i should say. 14:48 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 14:48 < gmaxwell> digi_james: Right. Though the cases where it helps are cases that we've never seen used on bitcoin. Even the highest number of combinations from single check multisig is perfectly computable. 14:48 < digi_james> : 14:48 < gmaxwell> (20 choose 10 is roughly 2^17.5) 14:49 < gmaxwell> so in terms of thinking about protocol complexity, it's hard to justify a much more complicated consensus rule which merely improves efficiency in unobservably rare use cases. 14:50 < sipa> especially now that the script size/sigops limits have been removed/relaxed 14:50 < sipa> before you could argue that many policies (albeit unusual/uninteresting ones) were actually impossible to implememt as a script 14:51 < sipa> now they're merely more costly to fully deal with 14:52 < gmaxwell> Whats the operative standardness limit on the number of checksigadds? 14:53 < sipa> 50 vbytes per sigop 14:53 < sipa> ah, standardness 14:53 < sipa> currengl 14:53 < sipa> currently my branch has none in addition to the consensus ones 14:54 < sipa> sorry, 50 wu per sigoo 14:56 < gmaxwell> So I could totally construct a 4 of 10,000 tapscript? e.g. with a bunch of if gated pushes then four checksigadds? 14:56 < sipa> right 14:57 < sipa> i believe you can, though you'll start running into transaction stadardness limits 14:57 < sipa> (400000 WU per tx) 15:02 < sipa> 0 (SWAP IF CSA ENDIF)*10000 4 EQUAL 15:02 < sipa> that will implement 4-of-10000 i think 15:03 < gmaxwell> I picked that number because it was under 400kWU. 15:03 < gmaxwell> cool. 15:03 < gmaxwell> At least then there won't be an non-efficiency reasons for people to refrain from such policies. 15:05 < sipa> 380010 kWU 15:05 < sipa> for the witness 15:05 < sipa> -k 15:06 < sipa> i should add that as a test 15:27 -!- Moller40_ [~mr@82.103.130.178] has quit [Quit: -a- IRC for Android 2.1.55] 15:29 < r251d> In the "Script validation rules" section of the taproot BIP, it took me embarassingly long to figure out that e_j are the unused ("excluded"?) branches of the MAST. Did I figure that out correctly, and could it help other readers to call out that e_j are hashes of those unexecuted ("excluded"?) branches? 15:30 < sipa> r251d: you read that right; if that it isn't clear, it's certainly worth improving 15:30 < sipa> the usual terminology for those is the "merkle path" or "merkle proof" 15:31 < sipa> but i don't think we're using either of those terms 15:31 -!- thestack [b2a583e0@178.165.131.224.wireless.dyn.drei.com] has joined ##taproot-bip-review 15:42 < r251d> I think I follow. The series e_j is the "Merkle proof" for leaf k_0 of a Merke tree with root k_m. Each e_j corresponds to a branch not executed except for proof that k_j is in the tree. 15:42 < r251d> Thanks for explaining. 15:44 < sipa> Right. 15:50 -!- pinheadmz [~matthewzi@185.217.69.139] has joined ##taproot-bip-review 15:51 -!- real_or_random [~real_or_r@173.249.7.254] has joined ##taproot-bip-review 15:54 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 245 seconds] 15:58 -!- Tibo [7c2353a2@124x35x83x162.ap124.ftth.ucom.ne.jp] has joined ##taproot-bip-review 16:14 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: notmandatory] 16:15 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Remote host closed the connection] 16:29 -!- soju [~soju@2601:640:8780:6d90:4405:30f3:b4a5:daaf] has joined ##taproot-bip-review 16:34 -!- soju [~soju@2601:640:8780:6d90:4405:30f3:b4a5:daaf] has quit [Ping timeout: 264 seconds] 16:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 16:54 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55] 16:57 -!- lightlike [~lightlike@2001:16b8:57b9:e300:b972:ebc5:eda7:44a] has quit [Quit: Leaving] 17:10 -!- pinheadmz [~matthewzi@185.217.69.139] has quit [Quit: pinheadmz] 17:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 17:27 -!- thestack [b2a583e0@178.165.131.224.wireless.dyn.drei.com] has quit [Remote host closed the connection] 17:49 -!- pglazman [~pglazman@205.209.24.227] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:01 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined ##taproot-bip-review 18:32 -!- nick_freeman [~nick_free@2001:16b8:307f:ca00:cc9b:604c:3a22:a4ef] has joined ##taproot-bip-review 18:36 -!- nick_fre_ [~nick_free@2001:16b8:3039:d800:f523:6112:fa56:6a24] has quit [Ping timeout: 264 seconds] 19:28 -!- pinheadmz [~matthewzi@45.61.14.174] has joined ##taproot-bip-review 19:37 -!- nick_freeman [~nick_free@2001:16b8:307f:ca00:cc9b:604c:3a22:a4ef] has quit [Remote host closed the connection] 19:42 -!- nick_freeman [~nick_free@2001:16b8:307f:ca00:595f:99ff:90cd:dbcb] has joined ##taproot-bip-review 20:10 -!- nick_freeman [~nick_free@2001:16b8:307f:ca00:595f:99ff:90cd:dbcb] has quit [Remote host closed the connection] 20:20 < instagibbs> r251d, i think those variables could stand to be named, I agree 20:31 -!- pinheadmz [~matthewzi@45.61.14.174] has quit [Quit: pinheadmz] 20:31 -!- pglazman [~pglazman@c-67-174-198-20.hsd1.ca.comcast.net] has joined ##taproot-bip-review 21:40 -!- pglazman [~pglazman@c-67-174-198-20.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:01 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 246 seconds] 22:26 -!- HighOnBtc [~Admin@86.121.55.235] has quit [Ping timeout: 276 seconds] 22:41 -!- xoyi- [~xoyi-@185.6.78.109] has joined ##taproot-bip-review 23:15 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 240 seconds]