12019-11-05T00:17:24  *** ilan has joined ##taproot-bip-review
  22019-11-05T00:19:50  *** lightlike has joined ##taproot-bip-review
  32019-11-05T00:25:20  <luke-jr> great
  42019-11-05T00:26:37  *** Chris_Stewart_5 has quit IRC
  52019-11-05T00:34:51  *** ilan has quit IRC
  62019-11-05T00:52:25  *** pglazman has joined ##taproot-bip-review
  72019-11-05T01:18:00  <afk11> date
  82019-11-05T01:18:01  *** pglazman has quit IRC
  92019-11-05T01:18:08  <afk11> heh.
 102019-11-05T02:05:56  *** soju has quit IRC
 112019-11-05T02:34:16  *** nick_fre_ has joined ##taproot-bip-review
 122019-11-05T02:36:57  *** nick_freeman has quit IRC
 132019-11-05T02:51:29  *** lightlike has quit IRC
 142019-11-05T04:21:38  *** pinheadmz has quit IRC
 152019-11-05T05:19:45  *** molz has joined ##taproot-bip-review
 162019-11-05T05:30:19  *** pglazman has joined ##taproot-bip-review
 172019-11-05T06:29:52  *** pglazman has quit IRC
 182019-11-05T06:42:27  *** soju has joined ##taproot-bip-review
 192019-11-05T06:47:53  *** soju has quit IRC
 202019-11-05T06:50:23  *** soju has joined ##taproot-bip-review
 212019-11-05T06:58:54  *** xoyi- has joined ##taproot-bip-review
 222019-11-05T07:44:23  *** soju has quit IRC
 232019-11-05T07:45:31  *** soju has joined ##taproot-bip-review
 242019-11-05T07:50:45  *** soju has quit IRC
 252019-11-05T08:56:53  *** b10c has joined ##taproot-bip-review
 262019-11-05T09:38:00  <waxwing> sosthene, how do we organise a time to meet here? i don't have people's IRC handles.
 272019-11-05T09:38:54  <sosthene> waxwing: I was about to create another channel and send an email to our group so that they join themselves
 282019-11-05T09:41:02  *** sosthene has quit IRC
 292019-11-05T09:41:17  <waxwing> ok cool. you have emails? i didn't see that.
 302019-11-05T09:42:17  *** sosthene has joined ##taproot-bip-review
 312019-11-05T09:42:53  <aj> waxwing: the "Taproot BIP Review Study Group" emails had all the reviewers' emails in the To: field
 322019-11-05T09:44:08  <waxwing> also i remember there's a meeting here at 1900 UTC today, that's a global QA session right? separate from the groups?
 332019-11-05T09:44:33  <waxwing> aj, sponsored by bitmex :)
 342019-11-05T09:45:23  <aj> waxwing: haha, just the emails for each individual group
 352019-11-05T10:10:22  *** orfeas has joined ##taproot-bip-review
 362019-11-05T10:16:20  *** amiti has joined ##taproot-bip-review
 372019-11-05T10:21:45  <orfeas> Good morning! I'm looking for a review groupI'd like to join yours if that's OK with you!(group 7 -- https://github.com/ajtowns/taproot-review/blob/master/study-groups.md#group-7---irc-1600-1700)
 382019-11-05T10:25:27  <nickler> orfeas: cool! feel free to join ##bitcoin-taproot-sg7
 392019-11-05T11:12:20  *** afk11 has quit IRC
 402019-11-05T11:13:21  *** afk11 has joined ##taproot-bip-review
 412019-11-05T11:26:53  *** lightlike has joined ##taproot-bip-review
 422019-11-05T11:45:40  *** Chris_Stewart_5 has joined ##taproot-bip-review
 432019-11-05T12:20:56  *** stacie has joined ##taproot-bip-review
 442019-11-05T12:22:59  *** stacie has quit IRC
 452019-11-05T12:23:58  *** stacie has joined ##taproot-bip-review
 462019-11-05T12:57:36  *** Chris_Stewart_5 has quit IRC
 472019-11-05T12:59:12  *** b10c has quit IRC
 482019-11-05T12:59:13  *** Chris_Stewart_5 has joined ##taproot-bip-review
 492019-11-05T14:15:43  *** stacie has quit IRC
 502019-11-05T14:16:38  *** stacie has joined ##taproot-bip-review
 512019-11-05T14:17:14  *** Chris_Stewart_5 has quit IRC
 522019-11-05T14:19:23  *** Chris_Stewart_5 has joined ##taproot-bip-review
 532019-11-05T14:59:03  *** felixweis has joined ##taproot-bip-review
 542019-11-05T15:04:28  *** xoyi- has quit IRC
 552019-11-05T15:08:24  *** pglazman has joined ##taproot-bip-review
 562019-11-05T15:25:19  *** pglazman has quit IRC
 572019-11-05T15:32:51  *** pinheadmz has joined ##taproot-bip-review
 582019-11-05T15:33:57  *** stacie has quit IRC
 592019-11-05T15:41:23  *** b10c has joined ##taproot-bip-review
 602019-11-05T15:49:04  *** jb55 has quit IRC
 612019-11-05T15:53:05  *** jb55 has joined ##taproot-bip-review
 622019-11-05T16:05:01  *** stacie has joined ##taproot-bip-review
 632019-11-05T16:07:19  *** xoyi- has joined ##taproot-bip-review
 642019-11-05T16:17:42  *** pglazman has joined ##taproot-bip-review
 652019-11-05T16:19:19  *** HighOnBtc has joined ##taproot-bip-review
 662019-11-05T16:21:40  *** HighOnBtc has quit IRC
 672019-11-05T16:22:43  *** HighOnBtc has joined ##taproot-bip-review
 682019-11-05T16:23:19  *** HighOnBtc has quit IRC
 692019-11-05T16:30:34  *** HighOnBtc has joined ##taproot-bip-review
 702019-11-05T16:31:35  *** HighOnBtc_ has joined ##taproot-bip-review
 712019-11-05T16:32:00  *** HighOnBtc_ is now known as High0nBtc
 722019-11-05T16:33:36  *** jamesasefa has joined ##taproot-bip-review
 732019-11-05T16:40:42  *** pinheadmz has quit IRC
 742019-11-05T16:43:09  *** wallet42 has left ##taproot-bip-review
 752019-11-05T16:50:34  *** pinheadmz has joined ##taproot-bip-review
 762019-11-05T17:06:01  *** le_chuck has joined ##taproot-bip-review
 772019-11-05T17:06:22  <le_chuck> ##taproot-bip-review-group2
 782019-11-05T17:06:26  <le_chuck> sry
 792019-11-05T17:06:41  *** pinheadmz has quit IRC
 802019-11-05T17:14:56  <sosthene> Hi everyone, I tried to build the taproot branch from sipa's Bitcoin repo, and I got the following error :
 812019-11-05T17:14:59  <sosthene> ./wallet/db.h:24:10: fatal error: db_cxx.h: No such file or directory
 822019-11-05T17:15:02  <sosthene>  #include <db_cxx.h>
 832019-11-05T17:15:20  <sosthene> does anyone have a clue why I miss a header file?
 842019-11-05T17:17:52  <sipa> sosthene: follow doc/build-unix.md
 852019-11-05T17:19:07  *** jenseven has joined ##taproot-bip-review
 862019-11-05T17:19:37  *** pinheadmz has joined ##taproot-bip-review
 872019-11-05T17:22:19  *** pinheadmz has quit IRC
 882019-11-05T17:25:13  <sosthene> sipa: it fails even faster with this error :
 892019-11-05T17:25:14  <sosthene> ./wallet/db.h:24:10: fatal error: db_cxx.h: No such file or directory
 902019-11-05T17:25:17  <sosthene>  #include <db_cxx.h>
 912019-11-05T17:25:40  *** pinheadmz has joined ##taproot-bip-review
 922019-11-05T17:25:41  *** xoyi- has quit IRC
 932019-11-05T17:25:44  <sosthene> Maybe my VM setup is a bit messy
 942019-11-05T17:28:21  *** orfeas has quit IRC
 952019-11-05T17:28:26  *** xoyi- has joined ##taproot-bip-review
 962019-11-05T17:28:59  <sosthene> yeah forgot make clean...
 972019-11-05T17:29:15  *** jamesasefa has quit IRC
 982019-11-05T17:29:31  <sosthene> but still fails
 992019-11-05T17:31:12  *** bjarnem has joined ##taproot-bip-review
1002019-11-05T17:33:08  *** chm-diederichs has joined ##taproot-bip-review
1012019-11-05T17:34:26  <jb55> sosthene: you're missing a dependency
1022019-11-05T17:59:05  *** jamesasefa has joined ##taproot-bip-review
1032019-11-05T18:09:19  *** pinheadmz has quit IRC
1042019-11-05T18:13:55  <sipa> sosthene: you need libdb++-dev, but you probably should first get familiar with building bitcoin core releases before diving into the taproot branch
1052019-11-05T18:14:07  *** pinheadmz has joined ##taproot-bip-review
1062019-11-05T18:21:33  *** Chris_Stewart_5 has quit IRC
1072019-11-05T18:27:57  *** stacie has quit IRC
1082019-11-05T18:30:04  *** pinheadmz has quit IRC
1092019-11-05T18:31:53  *** pinheadmz has joined ##taproot-bip-review
1102019-11-05T18:38:27  *** andytoshi has joined ##taproot-bip-review
1112019-11-05T18:39:08  *** Chris_Stewart_5 has joined ##taproot-bip-review
1122019-11-05T18:41:45  *** stacie has joined ##taproot-bip-review
1132019-11-05T18:44:05  *** le_chuck has quit IRC
1142019-11-05T18:45:33  <aj> hmm, 15m away
1152019-11-05T18:46:36  *** soju has joined ##taproot-bip-review
1162019-11-05T18:49:38  *** Moller40 has joined ##taproot-bip-review
1172019-11-05T18:50:18  *** soju has quit IRC
1182019-11-05T18:51:25  <andytoshi> i have another meeting on top of this one. will be online and try to answer questions. sorry. daylight savings rearranged my schedule.
1192019-11-05T18:53:27  *** jamesasefa has left ##taproot-bip-review
1202019-11-05T18:54:00  *** pinheadmz has quit IRC
1212019-11-05T18:56:15  *** pinheadmz has joined ##taproot-bip-review
1222019-11-05T18:56:56  <r251d> Group #13 is scheduled to meet over Hangouts. Is there a particular Hangouts "group" to join for that or a recommendation for how to coordinate?
1232019-11-05T18:57:35  <sipa> r251d: you should coordinate with your group; you should have their email addresses
1242019-11-05T18:58:55  <r251d> Will do. Thanks.
1252019-11-05T19:00:05  *** pinheadmz has quit IRC
1262019-11-05T19:00:29  <pyskell> So how does this global Q&A go now, do we need to start the logging bot?
1272019-11-05T19:00:40  <pyskell> ping moneyball
1282019-11-05T19:00:42  <aj> #startmeeting
1292019-11-05T19:00:42  <lightningbot> Meeting started Tue Nov  5 19:00:42 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
1302019-11-05T19:00:42  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
1312019-11-05T19:00:46  <moneyball> hi
1322019-11-05T19:00:51  <sipa> hi
1332019-11-05T19:01:04  <hebasto> hi
1342019-11-05T19:01:08  <gmaxwell> hi
1352019-11-05T19:01:08  <schmidty> hi
1362019-11-05T19:01:12  <andytoshi> hi
1372019-11-05T19:01:13  <aj> hi!
1382019-11-05T19:01:13  <pyskell> hi
1392019-11-05T19:01:16  <jonatack> hi
1402019-11-05T19:01:17  <kabaum> hi
1412019-11-05T19:01:18  <afk11> hi all
1422019-11-05T19:01:21  <pglazman> hi
1432019-11-05T19:01:23  <ariard> hi
1442019-11-05T19:01:29  <fjahr> hi
1452019-11-05T19:01:33  <bjarnem> hi
1462019-11-05T19:01:34  <amiti> hi
1472019-11-05T19:01:39  <cdecker> Hi
1482019-11-05T19:02:13  <moneyball> good turnout! ok we have several experts here. so, ask away!
1492019-11-05T19:02:43  <nickler> when will we get schnorr in bitcoin?
1502019-11-05T19:02:47  <pyskell> So, question, I know the expected use of the public key in a taproot script is to allow for a happy path cooperative close but is this something that you think will be misused such that most taproot contracts end up with a defacto single owner?
1512019-11-05T19:02:52  <jnewbery> hi
1522019-11-05T19:02:55  <jonatack> Group 5 just met for the first time this past hour... constructive.
1532019-11-05T19:03:01  <aj> nickler: #twoweeks, aiui
1542019-11-05T19:03:24  <b10c> hi
1552019-11-05T19:03:25  <jb55> hi
1562019-11-05T19:03:32  <jkczyz> hi
1572019-11-05T19:03:47  <hebasto> kabaum: please bring Group 5 questions
1582019-11-05T19:03:48  <sipa> pyskell: i don't think so, or at least not anymore than the fact that P2(W)PKH is easier to deal with than P2(W)SH encourages people to pick a single-key policy
1592019-11-05T19:03:56  <bjarnem> Q: I am not sure I understand the purpose of annex? Segwit supports versioning, where Taproot makes use of v1. Does using annex allow for something like subversioning to extend taproot without using up Segwit versions? Do we know of any examples for what this could be used for?
1602019-11-05T19:04:08  <andytoshi> pyskell: it's not "misuse" if there really is a single owner :)
1612019-11-05T19:04:16  <kabaum> Q from group 5 (1/8): We were wondering if there should be a rule in "Script validation rules" that the scriptSig must be empty?
1622019-11-05T19:04:24  <sipa> bjarnem: rather the opposite, because even more complex things do become relatively cheaper
1632019-11-05T19:04:35  <sipa> kabaum: there is, see BIp141
1642019-11-05T19:04:39  <andytoshi> my guess would be that few people are trying to handroll their own multiparty protocols and screw it up in a way that one party controls all the funds. that would be a serious bug in their protocol.
1652019-11-05T19:04:51  <aj> bjarnem: annex lets us commit to extra information in the signatures, so is an upgrade method. should become clearer when we look into the signature details more in depth, and the upgrade methods in particular afterwards
1662019-11-05T19:04:52  *** arik_ has joined ##taproot-bip-review
1672019-11-05T19:05:00  <sipa> kabaum: BIP141 requires an empty scriptSig when using non-P2SH-segwit
1682019-11-05T19:05:15  <kabaum> sipa: that only applies to v0 native segwit, right?
1692019-11-05T19:05:15  <sipa> taproot cannot change that
1702019-11-05T19:05:23  <sipa> kabaum: no, it applies to all segwit
1712019-11-05T19:05:49  <gmaxwell> sipa: the redeemscript is still there for p2sh compatible witness.
1722019-11-05T19:06:26  <sipa> gmaxwell: indeed; but since the current taproot draft requires non-p2sh that isn't relevant
1732019-11-05T19:06:58  <sipa> kabaum: reading BIP141, this is actually not clear
1742019-11-05T19:07:18  <hebasto> ^
1752019-11-05T19:07:22  <jonatack> ^\
1762019-11-05T19:08:07  <ariard> why taproot first and not grafroot, apart of signing keys required to be online, grafroot benefits seem to encompass all taproot ones ?
1772019-11-05T19:08:31  <sipa> ariard: "apart of" seems like an enormous disadvantage
1782019-11-05T19:08:35  <aj> sipa: "Witness Program" section "Triggered by a scriptPubKey .." item says " The scriptSig must be exactly empty or validation fails." ?
1792019-11-05T19:08:54  <pyskell> sipa, Gotcha, so there are already existing multisigs that can allow a single specific key to spend but not the other keys?
1802019-11-05T19:09:07  <andytoshi> ariard: graftroot requires interaction and involves non-reproducible (by individual parties) data that must be storied
1812019-11-05T19:09:44  <felixweis> what happens if there is an annex and key path spending?
1822019-11-05T19:09:47  *** pinheadmz has joined ##taproot-bip-review
1832019-11-05T19:09:57  <andytoshi> you also can't prove, with graftroot, the total set of spending conditions that exist (which you can be revealing all leaves of a taproot tree)
1842019-11-05T19:10:03  <nickler> ariard: also graftroot spend is larger (one sig vs one point). Can be made the same with "half aggregation".
1852019-11-05T19:10:22  <hebasto> felixweis: annex discards, no?
1862019-11-05T19:10:23  <aj> andytoshi, ariard: also graftroot is more efficient if we have signature half-aggregation, which wasn't worked out
1872019-11-05T19:10:29  <sipa> ariard: i think graftroot is great and i have some ideas on how to integrate it, but it's not applicable in all cases where taproot/schnorr/musig are useful (which don't have any interactive setup before the address can be constructed, don't need private keys online, can be computed from just xpubs, ...)
1882019-11-05T19:10:31  <ariard> sipa: ok and with taproot I can create a taptree using bip32 derivation to include some of your keys without interactivity
1892019-11-05T19:10:41  <sipa> ariard: exactly
1902019-11-05T19:10:55  <sipa> without taking your paper wallets out of your safe
1912019-11-05T19:10:58  <gmaxwell> and having to securely store and backup that data is seen to be a big issue.  (consider how often people want metal etched key backups and such). And half aggregation makes it efficient, HOWEVER, halfagg has the same sorts of challenges proving its security.
1922019-11-05T19:11:00  <sipa> without needing to talk to your GSM
1932019-11-05T19:11:02  <sipa> *HSM
1942019-11-05T19:11:04  <ariard> andytoshi: can't you be ambiguous on this, find some script collusiojn ?
1952019-11-05T19:11:10  <afk11> felixweis: key-path spend is only possible when there is exactly 1 value on the stack.
1962019-11-05T19:11:40  <sipa> afk11: *after* the annex is dropped; an annex is allowed with key path spending
1972019-11-05T19:11:42  <aj> felixweis: an annex with key path spending just has the annex contents committed to as part of the signature, which is the same as script path spending; as well as whatever constraints are imposed by later soft-forks by having info in the annex
1982019-11-05T19:11:43  <felixweis> afk11: the way i read it, there can be an annex and then there is only a sig left
1992019-11-05T19:11:52  <sipa> felixweis: correct
2002019-11-05T19:12:20  <andytoshi> ariard: i don't think you can find a script collision with 256-bit hashes. if i understand what you mean
2012019-11-05T19:12:20  <felixweis> can this be (ab)used for a cheaper per input op_return commitment?
2022019-11-05T19:12:29  <sipa> pyskell: i don't see your question is related to anything else said here
2032019-11-05T19:12:36  <sipa> felixweis: annexes are nonstandard
2042019-11-05T19:12:52  <ariard> sipa: okay maybe underline somewhere in the BIP the non-interactivty advantage like in taptree construction
2052019-11-05T19:13:01  <ariard> or in a footnote
2062019-11-05T19:13:23  <kabaum> Q from group 5 (2/8): Could we use the term p2tpk for taproot outputs? Or is there a common term for it already? p2tpk, p2tr, p2tap, etc?
2072019-11-05T19:13:39  <sipa> i've been using P2TR; i have no opinion beyond that
2082019-11-05T19:13:47  <pyskell> sipa: re: "pyskell: i don't think so, or at least not anymore than the fact that P2(W)PKH is easier to deal with than P2(W)SH encourages people to pick a single-key policy"
2092019-11-05T19:14:04  <sipa> pyskell: yes, i don't see how your question is related to that; i may have understood your question
2102019-11-05T19:14:17  <gmaxwell> will there have to be a new name for every output type in the future perhaps just start calling them P2WvN ? :P
2112019-11-05T19:14:27  <sipa> pyskell: let me restate how i interpreted your initial question
2122019-11-05T19:14:50  <hebasto> gmaxwell: great!
2132019-11-05T19:15:19  <sipa> pyskell: "is there a risk that people will be incentivized to use just single-key spending in taproot, as it's simpler than dealing with scripts?"
2142019-11-05T19:15:42  <sipa> pyskell: my answer to that is no, because that risk inevitably exists, but it's significantly reduced with taproot
2152019-11-05T19:15:50  <sipa> (due to lower costs of complex policies)
2162019-11-05T19:16:11  <sipa> but none of that has anything to do with complex policies involving a specific signer, so i don't know what you mean :)
2172019-11-05T19:16:31  <kabaum> Q from group 5 (3/8): Why allow other witness program lengths than 32 in taproot bip when disallowed in BIP141?
2182019-11-05T19:16:42  <sipa> kabaum: this was a stupid oversight in BIP141
2192019-11-05T19:16:45  <pyskell> Ahh, that's not what I meant, let me try to restate
2202019-11-05T19:16:50  <aj> pyskell: one of the ideas is that you can do multisig via a single key and single signature using muSig and similar constructions
2212019-11-05T19:17:02  <sipa> kabaum: it needlessly removed an upgrade potential
2222019-11-05T19:17:17  <kabaum> sipa: got it.
2232019-11-05T19:17:58  *** bjarnem has quit IRC
2242019-11-05T19:18:03  <sipa> kabaum: cool.
2252019-11-05T19:18:08  <gmaxwell> sipa: Clarification requested, uh, will the address encoding for P2TR (whatever you want to call it) still be able to fix the length?  If it cannot there is a reduction in address corruption robustness.
2262019-11-05T19:18:30  *** bjarnem has joined ##taproot-bip-review
2272019-11-05T19:19:07  <sipa> gmaxwell: not sure what you mean
2282019-11-05T19:19:30  <sipa> gmaxwell: are you referring to the insert/delete of q's in the 2nd to last position issue?
2292019-11-05T19:20:03  <andytoshi> that is my read of gmax's question, yes
2302019-11-05T19:20:23  <andytoshi> if i slip up and add a q to my address, will that result in miner-stealable coins?
2312019-11-05T19:20:32  <gmaxwell> sipa: BECH32 doesn't itself provide strong guarentees that an address where the user has deleted or inserted characters will be detected (bad addresses are not detected with 1:2^30 ish chance), but since there are only a few acceptable lengths for v0 this doesn't apply there.
2322019-11-05T19:20:59  <gmaxwell> andytoshi: the checksum still makes it unlikely.
2332019-11-05T19:21:21  <gmaxwell> (it's offset so adding q's shouldn't work)
2342019-11-05T19:21:37  <sipa> gmaxwell: inserting a q in the second to last position works
2352019-11-05T19:21:45  <gmaxwell> thats unfortunate.
2362019-11-05T19:21:54  <sipa> gmaxwell: yeah, this is an argument to maybe outlaw 31/33 byte v1 witness programs
2372019-11-05T19:22:21  <xoyi-> Q: If I understand correctly, Taproot is most beneficial when the key spending path is used. Do we have any statistics on how often such a cooperative branch is present in past contracts, and how often it's in fact used when spending?
2382019-11-05T19:22:32  <jb55> you can insert multiple q's no?
2392019-11-05T19:22:38  <sipa> jb55: yes
2402019-11-05T19:23:03  <gmaxwell> sipa: okay, we can discuss another time, I think it can be fixed without removing the ability e.g. to deploy a larger key in the future.
2412019-11-05T19:23:20  <pyskell> Are there risks that people choose to construct Taproot scripts such that the key-based spending path (P2PK) is a single key and the P2SH MuSigs are several m-of-ms that represent the intended say 2-of-3 multisig. You may (or may not) end up with a situation where participants are unaware that the key-based spending path has this property.
2422019-11-05T19:23:42  <sipa> jb55: though inserting 2 q's will actually be invalid bech32, due to the 8-to-5 bit conversion resulting in an invalid length
2432019-11-05T19:23:49  <andytoshi> my suggestion would be to add a rule to bech32 saying "if the hrp is bc1, or whatever the taproot hrp is, then the length is fixed" ... so on the consensus layer there's still upgrade potential but you have to change the hrp to access it
2442019-11-05T19:24:07  <andytoshi> simply banning 31/33-byte scripts in consensus changes "miner-stealable coins" to "burned coins"
2452019-11-05T19:24:12  <andytoshi> anyway. probably not the right venue for this
2462019-11-05T19:24:20  <pyskell> Follow-up question then, is it possible for any individual participant to know that they are included in the key-based spending path?
2472019-11-05T19:24:29  <andytoshi> pyskell: yep, with musig :)
2482019-11-05T19:24:32  <gmaxwell> andytoshi: a ban of 31/33 would come with a tightening of bech32 rules.
2492019-11-05T19:24:35  *** ni638629 has joined ##taproot-bip-review
2502019-11-05T19:24:45  <pyskell> andytoshi, lol I need to read more on MuSig then
2512019-11-05T19:24:53  <kabaum> Q from group 5 (4/8): Is collision security the main, or only, rationale for not supporting p2sh-wrapping, and if not, maybe we should discuss the other ones in rationale too?
2522019-11-05T19:25:01  <andytoshi> pyskell: if the individual participants' keys are combined using MuSig, it is trivial to verify this and impossible to demonstrate that any other set of keys was used
2532019-11-05T19:25:07  <andytoshi> so you get a proof of the full set of participants
2542019-11-05T19:25:16  <gmaxwell> pyskell: yes, they'll know as part of the process of constructing that key.  like how do you know you're included in a p2sh address?
2552019-11-05T19:25:49  <andytoshi> kabaum: well, from a wallet implementors' perspective, p2sh sucks and i wish i could forget it exists. but i don't know that that should appear in the official rationale
2562019-11-05T19:26:04  <sipa> pyskell: or in general: you can show anyone how the key was constructed from inner key and scripts (where the latter may involve keys again)... since the p2c construction is preimage resistant, if you know how a way how it was constructed, you know it is *the* way it was constructed
2572019-11-05T19:26:31  <kabaum> andytoshi: lol
2582019-11-05T19:26:38  <gmaxwell> kabaum: The p2sh wrapping has a number of points against it-- more cases to deal with and test, less efficient when spent on the network...  Basically p2sh wrapping never would have existed except for backwards compatiblity, but I think people feel now that native support is widespread enough that this is no longer a huge concern justifying p2sh wrapping's cost.
2592019-11-05T19:26:42  <sipa> kabaum: another reason in fungiblity; the taproot advantage of "all outputs and cooperative spends look indistinguishable" is simply much stronger if there are not two distinguishable versions!
2602019-11-05T19:26:47  <felixweis> the wallet implementors were encouraged currently to warn but not forbid the user when entereing a currently anyone-can-spend future segwit upgrade no?
2612019-11-05T19:27:06  *** michaelfolkson has joined ##taproot-bip-review
2622019-11-05T19:27:26  <gmaxwell> good point from sipa there.
2632019-11-05T19:27:39  <sipa> i think it's reasonable to add a short rationale for why no p2sh support in bip-taproot
2642019-11-05T19:27:50  <jb55> kabaum sipa: yeah perhaps these could be added to the bip, only the collision rationale is in there
2652019-11-05T19:27:57  <felixweis> actually reducing tech debt?
2662019-11-05T19:28:04  <gmaxwell> kabaum: for extra context, there were several discussions about leaving out p2sh wrappin in segwit itself back when it was done.  Or at least I know I certantly felt like I had to fight to keep it in! :)
2672019-11-05T19:28:36  <pyskell> gmaxwell, I construct the script, and now I see what you all mean, thanks
2682019-11-05T19:29:32  *** soju has joined ##taproot-bip-review
2692019-11-05T19:29:37  <kabaum> Q from group 5 (6/8): In "Security": All content in this section seems to be more related to privacy than security. Should the header possibly be Privacy instead?
2702019-11-05T19:30:30  <nickler> fine with me, hopefully we get a real security section at some point :)
2712019-11-05T19:30:43  <gmaxwell> perhaps instead terms like soundness, completeness, and confidentiality should be used in BIPs instead of "security".
2722019-11-05T19:30:47  <sipa> kabaum: i think we have a todo to add links to security proofs we have (including andytoshi's writeup), so it should be added there too
2732019-11-05T19:31:12  <gmaxwell> Privacy is a security property, but it seems some people expect security to refer only to soundness.
2742019-11-05T19:32:24  <jonatack> kabaum: (i think you skipped Q 5/8)
2752019-11-05T19:32:34  <sipa> and then the section can still be called security, but have subsections for the various specific properties
2762019-11-05T19:33:05  <kabaum> jonatack: Yep!
2772019-11-05T19:33:10  <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?
2782019-11-05T19:33:32  <sipa> kabaum: that sounds like a mistake indeed
2792019-11-05T19:33:35  <nickler> yes
2802019-11-05T19:34:31  <kabaum> thank you all for putting up with all questions.
2812019-11-05T19:34:32  <kabaum> Q from group 5 (7/8): "Design": "strong security assumptions" - Is that currently just DLP?
2822019-11-05T19:34:46  <jnewbery> I think that whole sentence could be removed. There are a whole list of things that wallet implementations can do to damage their privacy. It shouldn't be the BIPs job to try to list them all.
2832019-11-05T19:35:15  <sipa> jnewbery: no, it's listing a technique that can optionally be used to improve privacy
2842019-11-05T19:35:40  *** instagibbs has joined ##taproot-bip-review
2852019-11-05T19:36:37  <sipa> kabaum: the most common one being ECDLP in the random oracle model
2862019-11-05T19:36:39  <gmaxwell> jnewbery: also it's good if specifications call out the known specific privacy considerations (positive or negative) of the specification.
2872019-11-05T19:37:00  <nickler> kabaum: also collision resistance of sha256
2882019-11-05T19:37:26  <sipa> kabaum: but there are multiple only partially overlapping sets of assumptions that are sufficient to prove security of schnorr (and presumably taproot in general)
2892019-11-05T19:37:43  <gmaxwell> Does there even exist a security proof that only assumes DLP and hash collision resistance?
2902019-11-05T19:37:53  *** kanzure has joined ##taproot-bip-review
2912019-11-05T19:37:53  <sipa> gmaxwell: i believe not
2922019-11-05T19:38:02  <gmaxwell> K. didn't think so.
2932019-11-05T19:38:11  <sipa> there is one that uses the generic group model on the curve + collision resistance on the hash function
2942019-11-05T19:38:20  <sipa> and one that uses DLP on the curve + ROM on the hash function
2952019-11-05T19:38:28  <sanket1729> I think the question might be better phrased as "What additional assumptions do we have that we did not have in bitcoin previously?"
2962019-11-05T19:38:36  <sipa> but not one with just DLP on the curve + collision resistance on the hash function
2972019-11-05T19:38:59  <sipa> sanket1729: that is of course a hard question, as we don't actually know all the assumptions that bitcoin needs for security
2982019-11-05T19:39:48  <kabaum> Q from group 5 (8/8): "Design": I'm not sure what strong security assumption actually means? Are there "weak" security assumptions?
2992019-11-05T19:40:09  <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.
3002019-11-05T19:40:22  <sipa> maybe it should just say "specific security assumptions" ?
3012019-11-05T19:40:34  <gmaxwell> sipa: I do believe that bip-taproot isn't intended to add any additional strong assumptions that we don't already have.
3022019-11-05T19:40:35  <andytoshi> jnewbery: if the full tree is never revealed that's not obvious to me
3032019-11-05T19:40:44  <andytoshi> you may even get better fingerprint resistance by using non-optimal trees
3042019-11-05T19:40:47  <sipa> gmaxwell: right, i agree! but being specific about is hard
3052019-11-05T19:41:07  <andytoshi> (if your usual spending cases only use low-depth paths it may look like you have fewer paths than you do)
3062019-11-05T19:41:21  <instagibbs> kabaum, assumptions can be considered stronger and weaker yes, but it might be a judgment call
3072019-11-05T19:41:34  *** moneyball changes topic 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"
3082019-11-05T19:41:43  <andytoshi> well there are things like "P ≠ NP" that you could consider to be a "weak" security assumption
3092019-11-05T19:41:57  <sipa> but we're not adding any of those
3102019-11-05T19:41:58  <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.
3112019-11-05T19:42:22  <sipa> if your point is we should avoid non-actionable advice, i agree
3122019-11-05T19:42:22  <gmaxwell> jnewbery: I think it is extremely useful advice but it could be stated better.
3132019-11-05T19:42:43  <sipa> but if it's too vague to be non-actionable, maybe it should just be made more specific
3142019-11-05T19:43:00  <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.
3152019-11-05T19:43:16  <hebasto> sipa: bip draft states: Not adding any new strong security assumptions. maybe remove "strong"?
3162019-11-05T19:43:21  <gmaxwell> I think the text is vague in its advice in part because it doesn't know in advance what forms will be common.
3172019-11-05T19:44:11  <andytoshi> hebasto: i agree with that
3182019-11-05T19:44:29  <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
3192019-11-05T19:44:41  <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)
3202019-11-05T19:44:49  <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
3212019-11-05T19:44:54  <andytoshi> well you could enumerate all the parts of bitcoin, observe that "taproot is secure" is not listed
3222019-11-05T19:44:59  *** michaelfolkson has quit IRC
3232019-11-05T19:45:25  <sipa> andytoshi: sure, you can come up with obvious models that are stupid but for which this is true
3242019-11-05T19:45:43  <gmaxwell> sipa: Strong assumption "Bitcoin is secure",   clearly bip-taproot is not secure under that assumption. :P
3252019-11-05T19:45:48  <andytoshi> jnewbery: that advice comes with pretty tough tradeoffs (extra protocol complexity, data that needs to be stored offline and can't be recreated)
3262019-11-05T19:45:54  <andytoshi> lack of accountability
3272019-11-05T19:46:01  <sipa> my point is that if we want to state something about a comparison with existing assumptions, we should state those assumptions
3282019-11-05T19:46:01  *** michaelfolkson has joined ##taproot-bip-review
3292019-11-05T19:46:27  <andytoshi> "taproot requires only that DL is hard in secp256k1 and that sha256 is a RO"
3302019-11-05T19:46:34  <gmaxwell> jnewbery: actually for many users the top key should probably be a 2 of 2. :P
3312019-11-05T19:46:43  <jnewbery> andytoshi: sorry - I meant implemented as a 2-of-2 for the internal pubkey. But perhaps we're getting too into the weeds
3322019-11-05T19:46:46  <gmaxwell> jnewbery: (in the case of a 2 of 3 policy)
3332019-11-05T19:46:54  <andytoshi> jnewbery: ah! yep i see
3342019-11-05T19:46:59  *** michaelfolkson has quit IRC
3352019-11-05T19:47:13  <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.
3362019-11-05T19:47:34  *** ni638629 has quit IRC
3372019-11-05T19:48:03  <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.
3382019-11-05T19:48:04  <sipa> andytoshi: with tagged hashes it's probably possible to make it slightly weaker (like DL hard secp256k1 and the SHA256 *transform* is RO)
3392019-11-05T19:48:14  <andytoshi> ah good point. bitcoin has no tagged hashes today.
3402019-11-05T19:48:30  <andytoshi> (though it should :P)
3412019-11-05T19:48:54  <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?
3422019-11-05T19:48:58  <hebasto> sipa: what is diff?
3432019-11-05T19:49:10  <sipa> hebasto: ?
3442019-11-05T19:49:26  <hebasto> sha256 is a RO vs SHA256 *transform* is R
3452019-11-05T19:49:30  <hebasto> *RO
3462019-11-05T19:49:30  <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.
3472019-11-05T19:49:40  <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
3482019-11-05T19:49:45  <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.
3492019-11-05T19:50:11  <aj> 10 minutes left, if anyone's been sitting on questions
3502019-11-05T19:50:14  <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)
3512019-11-05T19:50:23  <sipa> hebasto: let me explain that after the meeting
3522019-11-05T19:50:32  <hebasto> sipa: ok
3532019-11-05T19:50:54  <sipa> at this point i'd like to avoid nits on the reference code
3542019-11-05T19:50:55  <ariard> about comparison with bip116 and bip114, it's next week?
3552019-11-05T19:51:19  <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
3562019-11-05T19:51:39  <aj> ariard: yeah, the MAST stuff is script path spends, so that sounds right
3572019-11-05T19:52:11  <ariard> aj: thnks holding mine then
3582019-11-05T19:52:11  <sipa> are there any other questions/topics?
3592019-11-05T19:52:21  <digi_james> I find MAST confusing as its not really an abstract syntax tree, but that's fine :)
3602019-11-05T19:52:37  <jnewbery> Merklized alternative script tree, you mean?
3612019-11-05T19:52:39  <aj> digi_james: "merklized alternative script tree" :)
3622019-11-05T19:52:46  <andytoshi> lol
3632019-11-05T19:52:55  <sipa> digi_james: note that bip-taproot never uses the name MAST (except when referring to an older proposal with that name)
3642019-11-05T19:53:10  <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 ;)
3652019-11-05T19:53:14  <digi_james> ha, sorry I thought it was abstract syntax tree all along
3662019-11-05T19:53:33  <andytoshi> i think it was, historically
3672019-11-05T19:53:39  <digi_james> right?
3682019-11-05T19:53:42  <sipa> digi_james: the name MAST comes from roconnor, and referred to what has now become simplicity
3692019-11-05T19:53:52  <aj> yeah, it was IF <hash> ELSE <other hash> ENDIF sort of
3702019-11-05T19:54:02  <sipa> what merkle branched script proposals used from that was not the abstract syntax tree part at all, just the merkle :)
3712019-11-05T19:54:10  <luke-jr> I thought it was jl
3722019-11-05T19:54:30  <sipa> oh, this was years earlier
3732019-11-05T19:54:32  <digi_james> Ok, so in that case the tree did encode syntax ...
3742019-11-05T19:54:44  <digi_james> Sorry - thanks for the history lesson :)
3752019-11-05T19:54:46  <instagibbs> russel -> jeremyrubin -> jl/maaku -> etc
3762019-11-05T19:54:56  <instagibbs> anyways not important...
3772019-11-05T19:55:09  <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 :)
3782019-11-05T19:56:01  <gmaxwell> just retcon the term to be a "merkelized arbritary script tree"
3792019-11-05T19:56:24  <sipa> 11:52:40 <@aj> digi_james: "merklized alternative script tree" :)
3802019-11-05T19:56:29  <andytoshi> merkleized arbitrary structure of things ;)
3812019-11-05T19:56:40  <ariard> but what bip-taproot doesn't hold as features compare to previous MAST proposals?
3822019-11-05T19:57:03  <ariard> on the high-level without getting into details
3832019-11-05T19:57:03  <andytoshi> ariard: ability to access the root (or other hashes) from within script is one
3842019-11-05T19:57:11  <sipa> ariard: there was an earlier proposal that supported multiple tree leaves simultaneously
3852019-11-05T19:57:13  <luke-jr> ariard: it's a merkle tree, but not of AST components
3862019-11-05T19:57:26  *** pinheadmz has quit IRC
3872019-11-05T19:57:43  <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
3882019-11-05T19:57:51  <ariard> andtyoshi: recursively executing another tree committed in one of the key included in a script?
3892019-11-05T19:57:53  <sipa> (to the best of my knowledge)
3902019-11-05T19:58:05  <andytoshi> ariard: yeah
3912019-11-05T19:58:21  <andytoshi> so like, you can't (efficiently) use taproot to implement keytrees in some cases
3922019-11-05T19:58:30  <andytoshi> like if you want to check 3 keytrees in a row or something
3932019-11-05T19:58:38  <ariard> sipa: could we execute multiple tapscript with a future taproot upgrade ?
3942019-11-05T19:58:40  <digi_james> ariard: Thinking of it, that seems pretty cool.
3952019-11-05T19:58:43  <andytoshi> you can't just do <root> OP_CHECKSIG <root 2> OP_CHECKSIG etc
3962019-11-05T19:58:55  <ariard> like leaf A || leaf B || leaf D
3972019-11-05T19:59:00  <sipa> ariard: not in the same way; it can always be done using script instructions that add that functionality inside script
3982019-11-05T19:59:16  <andytoshi> well, the choice that taproot makes has the nice property that it minimizes design surface
3992019-11-05T19:59:21  <gmaxwell> andytoshi: or if you have a bag of keys and want to yank out multiple leaves.
4002019-11-05T19:59:22  <andytoshi> which makes consensus easier to get :)
4012019-11-05T19:59:32  <andytoshi> gmaxwell: ah yeah!
4022019-11-05T19:59:37  <ariard> sipa: not with some kind of tail-call semantic or weird pubkey type?
4032019-11-05T19:59:48  <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?
4042019-11-05T19:59:49  <ariard> a bit hacky
4052019-11-05T19:59:50  <digi_james> Hm, are there any advantages having multiple "roots" in a tapscript to vs just separate leafs?
4062019-11-05T20:00:16  <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?
4072019-11-05T20:00:21  <digi_james> In and AND construct, they have to be revealed anyhow, and with OR, may as well ad a tapleaf
4082019-11-05T20:00:31  <sipa> instagibbs: because it has literally zero downsides :)
4092019-11-05T20:00:52  <instagibbs> sipa, well, I can make some painfully obtuse design decisions otherwise ;)
4102019-11-05T20:01:18  <instagibbs> fair enough
4112019-11-05T20:01:18  <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)
4122019-11-05T20:01:29  <sipa> it is easily possible as a script
4132019-11-05T20:01:31  <gmaxwell> sipa: outlawed and or how it interacts with bech32.
4142019-11-05T20:01:47  <sipa> gmaxwell: yeah
4152019-11-05T20:01:54  <sipa> oh, bad example
4162019-11-05T20:01:58  <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.
4172019-11-05T20:02:18  <aj> sipa: officially overtime now, shall we stop meetbot logging and leave it for regular chatting?
4182019-11-05T20:02:23  <sipa> yeah
4192019-11-05T20:02:26  <aj> #endmeeting
4202019-11-05T20:02:26  <lightningbot> Meeting ended Tue Nov  5 20:02:26 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4212019-11-05T20:02:26  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.html
4222019-11-05T20:02:26  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.txt
4232019-11-05T20:02:26  <lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html
4242019-11-05T20:02:28  <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
4252019-11-05T20:02:29  <digi_james> gmaxwell: Right .. thank you
4262019-11-05T20:02:30  <jonatack> sipa: iirc there are 3 changes/todos in this discussion
4272019-11-05T20:02:43  <moneyball> thank you to everyone for great participation!
4282019-11-05T20:02:44  <kabaum> sipa: from our point of view, yes, unless question 5/8 is considered semantics.
4292019-11-05T20:02:54  <kabaum> Thank you sooo much for your time, btc gurus. Love, group 5.
4302019-11-05T20:03:09  <sipa> but with a way to prove multiple branches simultaneously, it would be significantly simpler
4312019-11-05T20:03:21  <aj> kabaum: great questions
4322019-11-05T20:03:26  <jonatack> kabaum: yes Q 5/8 and possibly s/Not adding any new strong security assumptions/Not adding any new security assumptions/
4332019-11-05T20:03:30  <sipa> kabaum: what was 5/8 ?
4342019-11-05T20:03:31  <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!
4352019-11-05T20:03:48  <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?
4362019-11-05T20:03:54  <sipa> jonatack: right, i meant semantical discussions; not just improvements to the writeup
4372019-11-05T20:04:00  <sipa> kabaum: oh, agree
4382019-11-05T20:04:11  <sipa> we can improve the actual suggested approach there
4392019-11-05T20:04:23  <jonatack> all good
4402019-11-05T20:04:34  <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.
4412019-11-05T20:04:51  <bjarnem> gmaxwell: Could you briefly explain why "[..] you should bubble up a more restrictive policy higher in your tree"?
4422019-11-05T20:05:06  <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
4432019-11-05T20:05:58  <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...
4442019-11-05T20:06:17  <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.
4452019-11-05T20:06:27  <hebasto> sipa: thanks
4462019-11-05T20:06:34  <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
4472019-11-05T20:06:38  <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
4482019-11-05T20:06:38  <gmaxwell> if they happen to be online.
4492019-11-05T20:06:50  <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
4502019-11-05T20:07:11  <instagibbs> yes you'd just do k-of-k leaves
4512019-11-05T20:07:48  <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
4522019-11-05T20:07:56  <bjarnem> gmaxwell: ah, I see now, gotcha!
4532019-11-05T20:07:59  <hebasto> sipa: i thought SHA256 *transform* refers to tagged hash...
4542019-11-05T20:08:15  <instagibbs> sipa, interested, just throw it my way
4552019-11-05T20:08:51  *** pglazman has quit IRC
4562019-11-05T20:09:33  <sipa> digi_james: so i guess the point is that taproot adds merkleization to the script structure, but not to script itself
4572019-11-05T20:10:07  <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
4582019-11-05T20:10:13  <sipa> though i believe those to be rare
4592019-11-05T20:10:14  <digi_james> sipa: Right - would be cool though :)
4602019-11-05T20:10:59  <bjarnem> thanks all for this nice session! see you next time!
4612019-11-05T20:11:02  *** bjarnem has left ##taproot-bip-review
4622019-11-05T20:12:05  <digi_james> I mean more efficient, like in the case you mentioned earlier (1 of 2) AND (1 of 2) AND ...).
4632019-11-05T20:12:19  <sipa> yes
4642019-11-05T20:12:32  <sipa> thank you for all the valuable input
4652019-11-05T20:13:43  <soju> thank you all!
4662019-11-05T20:13:58  <digi_james> Thank you, bb
4672019-11-05T20:14:38  <cdecker> Thanks for organizing ^^
4682019-11-05T20:22:29  <kabaum> Thank you!
4692019-11-05T20:25:22  <xoyi-> Thanks, bye all!
4702019-11-05T20:28:32  *** notmandatory has joined ##taproot-bip-review
4712019-11-05T20:31:08  *** achow101 has joined ##taproot-bip-review
4722019-11-05T20:32:28  *** ajonas has joined ##taproot-bip-review
4732019-11-05T20:34:22  *** andytoshi has quit IRC
4742019-11-05T20:36:20  *** jonatack has quit IRC
4752019-11-05T20:36:34  *** xoyi- has quit IRC
4762019-11-05T20:38:40  *** devrandom has joined ##taproot-bip-review
4772019-11-05T20:39:38  *** devrandom has quit IRC
4782019-11-05T20:42:33  *** devrandom has joined ##taproot-bip-review
4792019-11-05T20:43:06  *** soju__ has joined ##taproot-bip-review
4802019-11-05T20:43:28  *** soju__ is now known as soju_
4812019-11-05T20:51:39  *** Moller40_ has joined ##taproot-bip-review
4822019-11-05T20:54:58  *** andytoshi has joined ##taproot-bip-review
4832019-11-05T20:55:41  *** Moller40 has quit IRC
4842019-11-05T21:01:06  *** jonatack has joined ##taproot-bip-review
4852019-11-05T21:08:46  *** soju has quit IRC
4862019-11-05T21:21: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:
4872019-11-05T21:21:37  <digi_james> (A|B|C|D) & (E|F|G|H) & (I|J|K|L) & (M|N|O|P)
4882019-11-05T21:21:49  <digi_james> With tapscript “merklescriptverify” opcodes: (2*4+1) * 32B = 9 * 32B proof (exact)
4892019-11-05T21:21:56  <digi_james> Without (using single pk tapleafs): 4*4*4*4 = 256 leafs,  8 * 32B proof (exact)
4902019-11-05T21:22:22  <sipa> digi_james: i'm talking about examples where the total number of combinations makes it intractible to completely expand out
4912019-11-05T21:22:22  <digi_james> (A|B|C|D|E) & (F|G|H|I|J) & (K|L|M|N|O) & (P|Q|R|S|T)
4922019-11-05T21:23:15  <sipa> if you can expand it out, thr taproot merkle tree is perfect
4932019-11-05T21:23:31  <digi_james> I must be missing something. Intuitively, the proof sizes grow O(log n) in both cases...
4942019-11-05T21:23:31  <sipa> but say there are 2^64 combinations, that'd not possoblr
4952019-11-05T21:23:53  <sipa> *that's not possible
4962019-11-05T21:25:08  <digi_james> Such as (1/2)&(1/2)&(1/2) .. x 64?
4972019-11-05T21:25:30  <sipa> yes, but that example isn't easy with merkle trees either
4982019-11-05T21:26:06  <sipa> but say (1 of 64) and (1 of 64) and (1 of 64) and ...
4992019-11-05T21:26:17  <digi_james> Hm ...
5002019-11-05T21:26:19  <sipa> until you have billions of combinations
5012019-11-05T21:27:11  <digi_james> so it would be <root of 64> "merklescriptverify" and <root of 64> "merklescriptverify" and ...etc.
5022019-11-05T21:27:17  <sipa> right
5032019-11-05T21:27:45  <sipa> it's even better if you want to do something like (4 of 64) and (4 of 64) and ...
5042019-11-05T21:28:06  <sipa> if your merkle verify opcode supports multiple branches simultaneously
5052019-11-05T21:28:32  <felixweis> i would also be interested in reading up on that g'root writeup
5062019-11-05T21:28:39  <digi_james> right ...
5072019-11-05T21:29:27  <digi_james> Is this part of graftroot? I am not sure.
5082019-11-05T21:29:42  <sipa> digi_james: no, completely unrelated
5092019-11-05T21:30:11  <nickler> g'root was mentioned on the mailing list? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html
5102019-11-05T21:30:24  <sipa> nickler: yes
5112019-11-05T21:30:51  <digi_james> nickler: Thanks a lot!
5122019-11-05T21:30:56  <sipa> digi_james: graftroot is very different from g'root, and both are unrelated to merkle branch verify
5132019-11-05T21:31:14  <felixweis> yes sorry for derailing
5142019-11-05T21:31:25  <felixweis> im just reading up on tapscript and the versioning
5152019-11-05T21:33:05  <felixweis> and was wondering if it's possible to sign off to delegate the spending on a future not yet defined tapscript version
5162019-11-05T21:33:25  <sipa> sure
5172019-11-05T21:33:28  <sipa> in theiry
5182019-11-05T21:33:30  <sipa> theory
5192019-11-05T21:34:07  <felixweis> to clarify, without sending it to a new ouput first
5202019-11-05T21:35:17  <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
5212019-11-05T21:35:23  <sipa> but that's a lot of hypotheticals
5222019-11-05T21:35:34  <digi_james> Hm... as I increase n for "<1/n> "merklescriptverify" and <r/n> "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.
5232019-11-05T21:40:14  <sipa> digi_james: again, i'm talking about a situation where you simply cannot expand it out
5242019-11-05T21:40:26  <sipa> as i said, if you can expand it, the taproot merkle tree is perfect
5252019-11-05T21:41:18  <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
5262019-11-05T21:42:37  <digi_james> Oh I see.  Why would it not be possible to expand any script with OR's?
5272019-11-05T21:43:30  <sipa> because say if there are say 2^64 combinations it's just computationally intractable to compute the address
5282019-11-05T21:43:40  <sipa> let alone sign for it
5292019-11-05T22:00:23  <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.
5302019-11-05T22:03:09  <sipa> digi_james: you simply cannot even iterate over 2^64 branches, let alone do 2^64 musig aggregations
5312019-11-05T22:03:15  <sipa> i mean, you can
5322019-11-05T22:03:29  <digi_james> right ... :)
5332019-11-05T22:04:22  <sipa> but there is some point where it simply goes from impractical to pointless
5342019-11-05T22:08:09  <digi_james> so this point is so far out, that it wouldn't be helpful to include a "merklescriptverify" opcode in tapscript?
5352019-11-05T22:08:32  <digi_james> "merkleverify"
5362019-11-05T22:09:15  <sipa> the reason it's not in there is that it can be done independently with no downside
5372019-11-05T22:10:35  <digi_james> another softfork?
5382019-11-05T22:11:01  <sipa> yes, if you like
5392019-11-05T22:11:35  <sipa> i mean, we have op_success for a reason, right
5402019-11-05T22:11:53  <digi_james> :)
5412019-11-05T22:12:41  <sipa> or not
5422019-11-05T22:12:44  <sipa> that's the point
5432019-11-05T22:12:57  <sipa> whether this is desirable should be an independent discussion
5442019-11-05T22:13:17  <sipa> and the nice thing is that doing it independently has no downside
5452019-11-05T22:17:48  *** b10c has quit IRC
5462019-11-05T22:18:03  *** pglazman has joined ##taproot-bip-review
5472019-11-05T22:19:19  <digi_james> sipa: Thank you!
5482019-11-05T22:27:38  *** michaelfolkson has joined ##taproot-bip-review
5492019-11-05T22:35:21  <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.
5502019-11-05T22:36:07  <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.
5512019-11-05T22:36:53  <sipa> right, tree depth is roughly proportional to the log2(1/probability) of the least-probable script in your tree
5522019-11-05T22:37:05  <sipa> but what we're talking about here is tree *size*, not depth
5532019-11-05T22:40:00  *** jeremyrubin has joined ##taproot-bip-review
5542019-11-05T22:40:51  *** Chris_Stewart_5 has quit IRC
5552019-11-05T22:45:02  <digi_james> sipa: gmaxwell: yes right - thanks I was (wrongly) focusing on depth because of inclusion proof, but merkleverify alleviates complexity from size/leafcount
5562019-11-05T22:48:00  *** Lexyon__ has joined ##taproot-bip-review
5572019-11-05T22:48:14  <digi_james> or complexity resulting from (very large) option count i should say.
5582019-11-05T22:48:17  *** stacie has quit IRC
5592019-11-05T22:48:20  <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.
5602019-11-05T22:48:50  <digi_james> :
5612019-11-05T22:48:51  <gmaxwell> (20 choose 10 is roughly 2^17.5)
5622019-11-05T22:49:38  <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.
5632019-11-05T22:50:23  <sipa> especially now that the script size/sigops limits have been removed/relaxed
5642019-11-05T22:50:57  <sipa> before you could argue that many policies (albeit unusual/uninteresting ones) were actually impossible to implememt as a script
5652019-11-05T22:51:14  <sipa> now they're merely more costly to fully deal with
5662019-11-05T22:52:28  <gmaxwell> Whats the operative standardness limit on the number of checksigadds?
5672019-11-05T22:53:13  <sipa> 50 vbytes per sigop
5682019-11-05T22:53:28  <sipa> ah, standardness
5692019-11-05T22:53:33  <sipa> currengl
5702019-11-05T22:53:44  <sipa> currently my branch has none in addition to the consensus ones
5712019-11-05T22:54:12  <sipa> sorry, 50 wu per sigoo
5722019-11-05T22:56:10  <gmaxwell> So I could totally construct a 4 of 10,000 tapscript?  e.g. with a bunch of if gated pushes then four checksigadds?
5732019-11-05T22:56:46  <sipa> right
5742019-11-05T22:57:39  <sipa> i believe you can, though you'll start running into transaction stadardness limits
5752019-11-05T22:57:47  <sipa> (400000 WU per tx)
5762019-11-05T23:02:10  <sipa> 0 (SWAP IF <key_i> CSA ENDIF)*10000 4 EQUAL
5772019-11-05T23:02:26  <sipa> that will implement 4-of-10000 i think
5782019-11-05T23:03:02  <gmaxwell> I picked that number because it was under 400kWU.
5792019-11-05T23:03:18  <gmaxwell> cool.
5802019-11-05T23:03:36  <gmaxwell> At least then there won't be an non-efficiency reasons for people to refrain from such policies.
5812019-11-05T23:05:15  <sipa> 380010 kWU
5822019-11-05T23:05:21  <sipa> for the witness
5832019-11-05T23:05:38  <sipa> -k
5842019-11-05T23:06:41  <sipa> i should add that as a test
5852019-11-05T23:27:47  *** Moller40_ has quit IRC
5862019-11-05T23:29:24  <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?
5872019-11-05T23:30:36  <sipa> r251d: you read that right; if that it isn't clear, it's certainly worth improving
5882019-11-05T23:30:54  <sipa> the usual terminology for those is the "merkle path" or "merkle proof"
5892019-11-05T23:31:03  <sipa> but i don't think we're using either of those terms
5902019-11-05T23:31:39  *** thestack has joined ##taproot-bip-review
5912019-11-05T23:42:07  <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.
5922019-11-05T23:42:12  <r251d> Thanks for explaining.
5932019-11-05T23:44:43  <sipa> Right.
5942019-11-05T23:50:32  *** pinheadmz has joined ##taproot-bip-review
5952019-11-05T23:51:43  *** real_or_random has joined ##taproot-bip-review
5962019-11-05T23:54:28  *** jonatack has quit IRC
5972019-11-05T23:58:51  *** Tibo has joined ##taproot-bip-review