1 2019-11-05T00:17:24  *** ilan has joined ##taproot-bip-review
  2 2019-11-05T00:19:50  *** lightlike has joined ##taproot-bip-review
  3 2019-11-05T00:25:20  <luke-jr> great
  4 2019-11-05T00:26:37  *** Chris_Stewart_5 has quit IRC
  5 2019-11-05T00:34:51  *** ilan has quit IRC
  6 2019-11-05T00:52:25  *** pglazman has joined ##taproot-bip-review
  7 2019-11-05T01:18:00  <afk11> date
  8 2019-11-05T01:18:01  *** pglazman has quit IRC
  9 2019-11-05T01:18:08  <afk11> heh.
 10 2019-11-05T02:05:56  *** soju has quit IRC
 11 2019-11-05T02:34:16  *** nick_fre_ has joined ##taproot-bip-review
 12 2019-11-05T02:36:57  *** nick_freeman has quit IRC
 13 2019-11-05T02:51:29  *** lightlike has quit IRC
 14 2019-11-05T04:21:38  *** pinheadmz has quit IRC
 15 2019-11-05T05:19:45  *** molz has joined ##taproot-bip-review
 16 2019-11-05T05:30:19  *** pglazman has joined ##taproot-bip-review
 17 2019-11-05T06:29:52  *** pglazman has quit IRC
 18 2019-11-05T06:42:27  *** soju has joined ##taproot-bip-review
 19 2019-11-05T06:47:53  *** soju has quit IRC
 20 2019-11-05T06:50:23  *** soju has joined ##taproot-bip-review
 21 2019-11-05T06:58:54  *** xoyi- has joined ##taproot-bip-review
 22 2019-11-05T07:44:23  *** soju has quit IRC
 23 2019-11-05T07:45:31  *** soju has joined ##taproot-bip-review
 24 2019-11-05T07:50:45  *** soju has quit IRC
 25 2019-11-05T08:56:53  *** b10c has joined ##taproot-bip-review
 26 2019-11-05T09:38:00  <waxwing> sosthene, how do we organise a time to meet here? i don't have people's IRC handles.
 27 2019-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
 28 2019-11-05T09:41:02  *** sosthene has quit IRC
 29 2019-11-05T09:41:17  <waxwing> ok cool. you have emails? i didn't see that.
 30 2019-11-05T09:42:17  *** sosthene has joined ##taproot-bip-review
 31 2019-11-05T09:42:53  <aj> waxwing: the "Taproot BIP Review Study Group" emails had all the reviewers' emails in the To: field
 32 2019-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?
 33 2019-11-05T09:44:33  <waxwing> aj, sponsored by bitmex :)
 34 2019-11-05T09:45:23  <aj> waxwing: haha, just the emails for each individual group
 35 2019-11-05T10:10:22  *** orfeas has joined ##taproot-bip-review
 36 2019-11-05T10:16:20  *** amiti has joined ##taproot-bip-review
 37 2019-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)
 38 2019-11-05T10:25:27  <nickler> orfeas: cool! feel free to join ##bitcoin-taproot-sg7
 39 2019-11-05T11:12:20  *** afk11 has quit IRC
 40 2019-11-05T11:13:21  *** afk11 has joined ##taproot-bip-review
 41 2019-11-05T11:26:53  *** lightlike has joined ##taproot-bip-review
 42 2019-11-05T11:45:40  *** Chris_Stewart_5 has joined ##taproot-bip-review
 43 2019-11-05T12:20:56  *** stacie has joined ##taproot-bip-review
 44 2019-11-05T12:22:59  *** stacie has quit IRC
 45 2019-11-05T12:23:58  *** stacie has joined ##taproot-bip-review
 46 2019-11-05T12:57:36  *** Chris_Stewart_5 has quit IRC
 47 2019-11-05T12:59:12  *** b10c has quit IRC
 48 2019-11-05T12:59:13  *** Chris_Stewart_5 has joined ##taproot-bip-review
 49 2019-11-05T14:15:43  *** stacie has quit IRC
 50 2019-11-05T14:16:38  *** stacie has joined ##taproot-bip-review
 51 2019-11-05T14:17:14  *** Chris_Stewart_5 has quit IRC
 52 2019-11-05T14:19:23  *** Chris_Stewart_5 has joined ##taproot-bip-review
 53 2019-11-05T14:59:03  *** felixweis has joined ##taproot-bip-review
 54 2019-11-05T15:04:28  *** xoyi- has quit IRC
 55 2019-11-05T15:08:24  *** pglazman has joined ##taproot-bip-review
 56 2019-11-05T15:25:19  *** pglazman has quit IRC
 57 2019-11-05T15:32:51  *** pinheadmz has joined ##taproot-bip-review
 58 2019-11-05T15:33:57  *** stacie has quit IRC
 59 2019-11-05T15:41:23  *** b10c has joined ##taproot-bip-review
 60 2019-11-05T15:49:04  *** jb55 has quit IRC
 61 2019-11-05T15:53:05  *** jb55 has joined ##taproot-bip-review
 62 2019-11-05T16:05:01  *** stacie has joined ##taproot-bip-review
 63 2019-11-05T16:07:19  *** xoyi- has joined ##taproot-bip-review
 64 2019-11-05T16:17:42  *** pglazman has joined ##taproot-bip-review
 65 2019-11-05T16:19:19  *** HighOnBtc has joined ##taproot-bip-review
 66 2019-11-05T16:21:40  *** HighOnBtc has quit IRC
 67 2019-11-05T16:22:43  *** HighOnBtc has joined ##taproot-bip-review
 68 2019-11-05T16:23:19  *** HighOnBtc has quit IRC
 69 2019-11-05T16:30:34  *** HighOnBtc has joined ##taproot-bip-review
 70 2019-11-05T16:31:35  *** HighOnBtc_ has joined ##taproot-bip-review
 71 2019-11-05T16:32:00  *** HighOnBtc_ is now known as High0nBtc
 72 2019-11-05T16:33:36  *** jamesasefa has joined ##taproot-bip-review
 73 2019-11-05T16:40:42  *** pinheadmz has quit IRC
 74 2019-11-05T16:43:09  *** wallet42 has left ##taproot-bip-review
 75 2019-11-05T16:50:34  *** pinheadmz has joined ##taproot-bip-review
 76 2019-11-05T17:06:01  *** le_chuck has joined ##taproot-bip-review
 77 2019-11-05T17:06:22  <le_chuck> ##taproot-bip-review-group2
 78 2019-11-05T17:06:26  <le_chuck> sry
 79 2019-11-05T17:06:41  *** pinheadmz has quit IRC
 80 2019-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 :
 81 2019-11-05T17:14:59  <sosthene> ./wallet/db.h:24:10: fatal error: db_cxx.h: No such file or directory
 82 2019-11-05T17:15:02  <sosthene>  #include <db_cxx.h>
 83 2019-11-05T17:15:20  <sosthene> does anyone have a clue why I miss a header file?
 84 2019-11-05T17:17:52  <sipa> sosthene: follow doc/build-unix.md
 85 2019-11-05T17:19:07  *** jenseven has joined ##taproot-bip-review
 86 2019-11-05T17:19:37  *** pinheadmz has joined ##taproot-bip-review
 87 2019-11-05T17:22:19  *** pinheadmz has quit IRC
 88 2019-11-05T17:25:13  <sosthene> sipa: it fails even faster with this error :
 89 2019-11-05T17:25:14  <sosthene> ./wallet/db.h:24:10: fatal error: db_cxx.h: No such file or directory
 90 2019-11-05T17:25:17  <sosthene>  #include <db_cxx.h>
 91 2019-11-05T17:25:40  *** pinheadmz has joined ##taproot-bip-review
 92 2019-11-05T17:25:41  *** xoyi- has quit IRC
 93 2019-11-05T17:25:44  <sosthene> Maybe my VM setup is a bit messy
 94 2019-11-05T17:28:21  *** orfeas has quit IRC
 95 2019-11-05T17:28:26  *** xoyi- has joined ##taproot-bip-review
 96 2019-11-05T17:28:59  <sosthene> yeah forgot make clean...
 97 2019-11-05T17:29:15  *** jamesasefa has quit IRC
 98 2019-11-05T17:29:31  <sosthene> but still fails
 99 2019-11-05T17:31:12  *** bjarnem has joined ##taproot-bip-review
100 2019-11-05T17:33:08  *** chm-diederichs has joined ##taproot-bip-review
101 2019-11-05T17:34:26  <jb55> sosthene: you're missing a dependency
102 2019-11-05T17:59:05  *** jamesasefa has joined ##taproot-bip-review
103 2019-11-05T18:09:19  *** pinheadmz has quit IRC
104 2019-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
105 2019-11-05T18:14:07  *** pinheadmz has joined ##taproot-bip-review
106 2019-11-05T18:21:33  *** Chris_Stewart_5 has quit IRC
107 2019-11-05T18:27:57  *** stacie has quit IRC
108 2019-11-05T18:30:04  *** pinheadmz has quit IRC
109 2019-11-05T18:31:53  *** pinheadmz has joined ##taproot-bip-review
110 2019-11-05T18:38:27  *** andytoshi has joined ##taproot-bip-review
111 2019-11-05T18:39:08  *** Chris_Stewart_5 has joined ##taproot-bip-review
112 2019-11-05T18:41:45  *** stacie has joined ##taproot-bip-review
113 2019-11-05T18:44:05  *** le_chuck has quit IRC
114 2019-11-05T18:45:33  <aj> hmm, 15m away
115 2019-11-05T18:46:36  *** soju has joined ##taproot-bip-review
116 2019-11-05T18:49:38  *** Moller40 has joined ##taproot-bip-review
117 2019-11-05T18:50:18  *** soju has quit IRC
118 2019-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.
119 2019-11-05T18:53:27  *** jamesasefa has left ##taproot-bip-review
120 2019-11-05T18:54:00  *** pinheadmz has quit IRC
121 2019-11-05T18:56:15  *** pinheadmz has joined ##taproot-bip-review
122 2019-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?
123 2019-11-05T18:57:35  <sipa> r251d: you should coordinate with your group; you should have their email addresses
124 2019-11-05T18:58:55  <r251d> Will do. Thanks.
125 2019-11-05T19:00:05  *** pinheadmz has quit IRC
126 2019-11-05T19:00:29  <pyskell> So how does this global Q&A go now, do we need to start the logging bot?
127 2019-11-05T19:00:40  <pyskell> ping moneyball
128 2019-11-05T19:00:42  <aj> #startmeeting
129 2019-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.
130 2019-11-05T19:00:42  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
131 2019-11-05T19:00:46  <moneyball> hi
132 2019-11-05T19:00:51  <sipa> hi
133 2019-11-05T19:01:04  <hebasto> hi
134 2019-11-05T19:01:08  <gmaxwell> hi
135 2019-11-05T19:01:08  <schmidty> hi
136 2019-11-05T19:01:12  <andytoshi> hi
137 2019-11-05T19:01:13  <aj> hi!
138 2019-11-05T19:01:13  <pyskell> hi
139 2019-11-05T19:01:16  <jonatack> hi
140 2019-11-05T19:01:17  <kabaum> hi
141 2019-11-05T19:01:18  <afk11> hi all
142 2019-11-05T19:01:21  <pglazman> hi
143 2019-11-05T19:01:23  <ariard> hi
144 2019-11-05T19:01:29  <fjahr> hi
145 2019-11-05T19:01:33  <bjarnem> hi
146 2019-11-05T19:01:34  <amiti> hi
147 2019-11-05T19:01:39  <cdecker> Hi
148 2019-11-05T19:02:13  <moneyball> good turnout! ok we have several experts here. so, ask away!
149 2019-11-05T19:02:43  <nickler> when will we get schnorr in bitcoin?
150 2019-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?
151 2019-11-05T19:02:52  <jnewbery> hi
152 2019-11-05T19:02:55  <jonatack> Group 5 just met for the first time this past hour... constructive.
153 2019-11-05T19:03:01  <aj> nickler: #twoweeks, aiui
154 2019-11-05T19:03:24  <b10c> hi
155 2019-11-05T19:03:25  <jb55> hi
156 2019-11-05T19:03:32  <jkczyz> hi
157 2019-11-05T19:03:47  <hebasto> kabaum: please bring Group 5 questions
158 2019-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
159 2019-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?
160 2019-11-05T19:04:08  <andytoshi> pyskell: it's not "misuse" if there really is a single owner :)
161 2019-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?
162 2019-11-05T19:04:24  <sipa> bjarnem: rather the opposite, because even more complex things do become relatively cheaper
163 2019-11-05T19:04:35  <sipa> kabaum: there is, see BIp141
164 2019-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.
165 2019-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
166 2019-11-05T19:04:52  *** arik_ has joined ##taproot-bip-review
167 2019-11-05T19:05:00  <sipa> kabaum: BIP141 requires an empty scriptSig when using non-P2SH-segwit
168 2019-11-05T19:05:15  <kabaum> sipa: that only applies to v0 native segwit, right?
169 2019-11-05T19:05:15  <sipa> taproot cannot change that
170 2019-11-05T19:05:23  <sipa> kabaum: no, it applies to all segwit
171 2019-11-05T19:05:49  <gmaxwell> sipa: the redeemscript is still there for p2sh compatible witness.
172 2019-11-05T19:06:26  <sipa> gmaxwell: indeed; but since the current taproot draft requires non-p2sh that isn't relevant
173 2019-11-05T19:06:58  <sipa> kabaum: reading BIP141, this is actually not clear
174 2019-11-05T19:07:18  <hebasto> ^
175 2019-11-05T19:07:22  <jonatack> ^\
176 2019-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 ?
177 2019-11-05T19:08:31  <sipa> ariard: "apart of" seems like an enormous disadvantage
178 2019-11-05T19:08:35  <aj> sipa: "Witness Program" section "Triggered by a scriptPubKey .." item says " The scriptSig must be exactly empty or validation fails." ?
179 2019-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?
180 2019-11-05T19:09:07  <andytoshi> ariard: graftroot requires interaction and involves non-reproducible (by individual parties) data that must be storied
181 2019-11-05T19:09:44  <felixweis> what happens if there is an annex and key path spending?
182 2019-11-05T19:09:47  *** pinheadmz has joined ##taproot-bip-review
183 2019-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)
184 2019-11-05T19:10:03  <nickler> ariard: also graftroot spend is larger (one sig vs one point). Can be made the same with "half aggregation".
185 2019-11-05T19:10:22  <hebasto> felixweis: annex discards, no?
186 2019-11-05T19:10:23  <aj> andytoshi, ariard: also graftroot is more efficient if we have signature half-aggregation, which wasn't worked out
187 2019-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, ...)
188 2019-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
189 2019-11-05T19:10:41  <sipa> ariard: exactly
190 2019-11-05T19:10:55  <sipa> without taking your paper wallets out of your safe
191 2019-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.
192 2019-11-05T19:11:00  <sipa> without needing to talk to your GSM
193 2019-11-05T19:11:02  <sipa> *HSM
194 2019-11-05T19:11:04  <ariard> andytoshi: can't you be ambiguous on this, find some script collusiojn ?
195 2019-11-05T19:11:10  <afk11> felixweis: key-path spend is only possible when there is exactly 1 value on the stack.
196 2019-11-05T19:11:40  <sipa> afk11: *after* the annex is dropped; an annex is allowed with key path spending
197 2019-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
198 2019-11-05T19:11:43  <felixweis> afk11: the way i read it, there can be an annex and then there is only a sig left
199 2019-11-05T19:11:52  <sipa> felixweis: correct
200 2019-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
201 2019-11-05T19:12:20  <felixweis> can this be (ab)used for a cheaper per input op_return commitment?
202 2019-11-05T19:12:29  <sipa> pyskell: i don't see your question is related to anything else said here
203 2019-11-05T19:12:36  <sipa> felixweis: annexes are nonstandard
204 2019-11-05T19:12:52  <ariard> sipa: okay maybe underline somewhere in the BIP the non-interactivty advantage like in taptree construction
205 2019-11-05T19:13:01  <ariard> or in a footnote
206 2019-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?
207 2019-11-05T19:13:39  <sipa> i've been using P2TR; i have no opinion beyond that
208 2019-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"
209 2019-11-05T19:14:04  <sipa> pyskell: yes, i don't see how your question is related to that; i may have understood your question
210 2019-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
211 2019-11-05T19:14:27  <sipa> pyskell: let me restate how i interpreted your initial question
212 2019-11-05T19:14:50  <hebasto> gmaxwell: great!
213 2019-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?"
214 2019-11-05T19:15:42  <sipa> pyskell: my answer to that is no, because that risk inevitably exists, but it's significantly reduced with taproot
215 2019-11-05T19:15:50  <sipa> (due to lower costs of complex policies)
216 2019-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 :)
217 2019-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?
218 2019-11-05T19:16:42  <sipa> kabaum: this was a stupid oversight in BIP141
219 2019-11-05T19:16:45  <pyskell> Ahh, that's not what I meant, let me try to restate
220 2019-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
221 2019-11-05T19:17:02  <sipa> kabaum: it needlessly removed an upgrade potential
222 2019-11-05T19:17:17  <kabaum> sipa: got it.
223 2019-11-05T19:17:58  *** bjarnem has quit IRC
224 2019-11-05T19:18:03  <sipa> kabaum: cool.
225 2019-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.
226 2019-11-05T19:18:30  *** bjarnem has joined ##taproot-bip-review
227 2019-11-05T19:19:07  <sipa> gmaxwell: not sure what you mean
228 2019-11-05T19:19:30  <sipa> gmaxwell: are you referring to the insert/delete of q's in the 2nd to last position issue?
229 2019-11-05T19:20:03  <andytoshi> that is my read of gmax's question, yes
230 2019-11-05T19:20:23  <andytoshi> if i slip up and add a q to my address, will that result in miner-stealable coins?
231 2019-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.
232 2019-11-05T19:20:59  <gmaxwell> andytoshi: the checksum still makes it unlikely.
233 2019-11-05T19:21:21  <gmaxwell> (it's offset so adding q's shouldn't work)
234 2019-11-05T19:21:37  <sipa> gmaxwell: inserting a q in the second to last position works
235 2019-11-05T19:21:45  <gmaxwell> thats unfortunate.
236 2019-11-05T19:21:54  <sipa> gmaxwell: yeah, this is an argument to maybe outlaw 31/33 byte v1 witness programs
237 2019-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?
238 2019-11-05T19:22:32  <jb55> you can insert multiple q's no?
239 2019-11-05T19:22:38  <sipa> jb55: yes
240 2019-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.
241 2019-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.
242 2019-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
243 2019-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
244 2019-11-05T19:24:07  <andytoshi> simply banning 31/33-byte scripts in consensus changes "miner-stealable coins" to "burned coins"
245 2019-11-05T19:24:12  <andytoshi> anyway. probably not the right venue for this
246 2019-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?
247 2019-11-05T19:24:29  <andytoshi> pyskell: yep, with musig :)
248 2019-11-05T19:24:32  <gmaxwell> andytoshi: a ban of 31/33 would come with a tightening of bech32 rules.
249 2019-11-05T19:24:35  *** ni638629 has joined ##taproot-bip-review
250 2019-11-05T19:24:45  <pyskell> andytoshi, lol I need to read more on MuSig then
251 2019-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?
252 2019-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
253 2019-11-05T19:25:07  <andytoshi> so you get a proof of the full set of participants
254 2019-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?
255 2019-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
256 2019-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
257 2019-11-05T19:26:31  <kabaum> andytoshi: lol
258 2019-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.
259 2019-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!
260 2019-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?
261 2019-11-05T19:27:06  *** michaelfolkson has joined ##taproot-bip-review
262 2019-11-05T19:27:26  <gmaxwell> good point from sipa there.
263 2019-11-05T19:27:39  <sipa> i think it's reasonable to add a short rationale for why no p2sh support in bip-taproot
264 2019-11-05T19:27:50  <jb55> kabaum sipa: yeah perhaps these could be added to the bip, only the collision rationale is in there
265 2019-11-05T19:27:57  <felixweis> actually reducing tech debt?
266 2019-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! :)
267 2019-11-05T19:28:36  <pyskell> gmaxwell, I construct the script, and now I see what you all mean, thanks
268 2019-11-05T19:29:32  *** soju has joined ##taproot-bip-review
269 2019-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?
270 2019-11-05T19:30:30  <nickler> fine with me, hopefully we get a real security section at some point :)
271 2019-11-05T19:30:43  <gmaxwell> perhaps instead terms like soundness, completeness, and confidentiality should be used in BIPs instead of "security".
272 2019-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
273 2019-11-05T19:31:12  <gmaxwell> Privacy is a security property, but it seems some people expect security to refer only to soundness.
274 2019-11-05T19:32:24  <jonatack> kabaum: (i think you skipped Q 5/8)
275 2019-11-05T19:32:34  <sipa> and then the section can still be called security, but have subsections for the various specific properties
276 2019-11-05T19:33:05  <kabaum> jonatack: Yep!
277 2019-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?
278 2019-11-05T19:33:32  <sipa> kabaum: that sounds like a mistake indeed
279 2019-11-05T19:33:35  <nickler> yes
280 2019-11-05T19:34:31  <kabaum> thank you all for putting up with all questions.
281 2019-11-05T19:34:32  <kabaum> Q from group 5 (7/8): "Design": "strong security assumptions" - Is that currently just DLP?
282 2019-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.
283 2019-11-05T19:35:15  <sipa> jnewbery: no, it's listing a technique that can optionally be used to improve privacy
284 2019-11-05T19:35:40  *** instagibbs has joined ##taproot-bip-review
285 2019-11-05T19:36:37  <sipa> kabaum: the most common one being ECDLP in the random oracle model
286 2019-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.
287 2019-11-05T19:37:00  <nickler> kabaum: also collision resistance of sha256
288 2019-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)
289 2019-11-05T19:37:43  <gmaxwell> Does there even exist a security proof that only assumes DLP and hash collision resistance?
290 2019-11-05T19:37:53  *** kanzure has joined ##taproot-bip-review
291 2019-11-05T19:37:53  <sipa> gmaxwell: i believe not
292 2019-11-05T19:38:02  <gmaxwell> K. didn't think so.
293 2019-11-05T19:38:11  <sipa> there is one that uses the generic group model on the curve + collision resistance on the hash function
294 2019-11-05T19:38:20  <sipa> and one that uses DLP on the curve + ROM on the hash function
295 2019-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?"
296 2019-11-05T19:38:36  <sipa> but not one with just DLP on the curve + collision resistance on the hash function
297 2019-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
298 2019-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?
299 2019-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.
300 2019-11-05T19:40:22  <sipa> maybe it should just say "specific security assumptions" ?
301 2019-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.
302 2019-11-05T19:40:35  <andytoshi> jnewbery: if the full tree is never revealed that's not obvious to me
303 2019-11-05T19:40:44  <andytoshi> you may even get better fingerprint resistance by using non-optimal trees
304 2019-11-05T19:40:47  <sipa> gmaxwell: right, i agree! but being specific about is hard
305 2019-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)
306 2019-11-05T19:41:21  <instagibbs> kabaum, assumptions can be considered stronger and weaker yes, but it might be a judgment call
307 2019-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"
308 2019-11-05T19:41:43  <andytoshi> well there are things like "P ≠ NP" that you could consider to be a "weak" security assumption
309 2019-11-05T19:41:57  <sipa> but we're not adding any of those
310 2019-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.
311 2019-11-05T19:42:22  <sipa> if your point is we should avoid non-actionable advice, i agree
312 2019-11-05T19:42:22  <gmaxwell> jnewbery: I think it is extremely useful advice but it could be stated better.
313 2019-11-05T19:42:43  <sipa> but if it's too vague to be non-actionable, maybe it should just be made more specific
314 2019-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.
315 2019-11-05T19:43:16  <hebasto> sipa: bip draft states: Not adding any new strong security assumptions. maybe remove "strong"?
316 2019-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.
317 2019-11-05T19:44:11  <andytoshi> hebasto: i agree with that
318 2019-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
319 2019-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)
320 2019-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
321 2019-11-05T19:44:54  <andytoshi> well you could enumerate all the parts of bitcoin, observe that "taproot is secure" is not listed
322 2019-11-05T19:44:59  *** michaelfolkson has quit IRC
323 2019-11-05T19:45:25  <sipa> andytoshi: sure, you can come up with obvious models that are stupid but for which this is true
324 2019-11-05T19:45:43  <gmaxwell> sipa: Strong assumption "Bitcoin is secure",   clearly bip-taproot is not secure under that assumption. :P
325 2019-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)
326 2019-11-05T19:45:54  <andytoshi> lack of accountability
327 2019-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
328 2019-11-05T19:46:01  *** michaelfolkson has joined ##taproot-bip-review
329 2019-11-05T19:46:27  <andytoshi> "taproot requires only that DL is hard in secp256k1 and that sha256 is a RO"
330 2019-11-05T19:46:34  <gmaxwell> jnewbery: actually for many users the top key should probably be a 2 of 2. :P
331 2019-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
332 2019-11-05T19:46:46  <gmaxwell> jnewbery: (in the case of a 2 of 3 policy)
333 2019-11-05T19:46:54  <andytoshi> jnewbery: ah! yep i see
334 2019-11-05T19:46:59  *** michaelfolkson has quit IRC
335 2019-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.
336 2019-11-05T19:47:34  *** ni638629 has quit IRC
337 2019-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.
338 2019-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)
339 2019-11-05T19:48:14  <andytoshi> ah good point. bitcoin has no tagged hashes today.
340 2019-11-05T19:48:30  <andytoshi> (though it should :P)
341 2019-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?
342 2019-11-05T19:48:58  <hebasto> sipa: what is diff?
343 2019-11-05T19:49:10  <sipa> hebasto: ?
344 2019-11-05T19:49:26  <hebasto> sha256 is a RO vs SHA256 *transform* is R
345 2019-11-05T19:49:30  <hebasto> *RO
346 2019-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.
347 2019-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
348 2019-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.
349 2019-11-05T19:50:11  <aj> 10 minutes left, if anyone's been sitting on questions
350 2019-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)
351 2019-11-05T19:50:23  <sipa> hebasto: let me explain that after the meeting
352 2019-11-05T19:50:32  <hebasto> sipa: ok
353 2019-11-05T19:50:54  <sipa> at this point i'd like to avoid nits on the reference code
354 2019-11-05T19:50:55  <ariard> about comparison with bip116 and bip114, it's next week?
355 2019-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
356 2019-11-05T19:51:39  <aj> ariard: yeah, the MAST stuff is script path spends, so that sounds right
357 2019-11-05T19:52:11  <ariard> aj: thnks holding mine then
358 2019-11-05T19:52:11  <sipa> are there any other questions/topics?
359 2019-11-05T19:52:21  <digi_james> I find MAST confusing as its not really an abstract syntax tree, but that's fine :)
360 2019-11-05T19:52:37  <jnewbery> Merklized alternative script tree, you mean?
361 2019-11-05T19:52:39  <aj> digi_james: "merklized alternative script tree" :)
362 2019-11-05T19:52:46  <andytoshi> lol
363 2019-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)
364 2019-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 ;)
365 2019-11-05T19:53:14  <digi_james> ha, sorry I thought it was abstract syntax tree all along
366 2019-11-05T19:53:33  <andytoshi> i think it was, historically
367 2019-11-05T19:53:39  <digi_james> right?
368 2019-11-05T19:53:42  <sipa> digi_james: the name MAST comes from roconnor, and referred to what has now become simplicity
369 2019-11-05T19:53:52  <aj> yeah, it was IF <hash> ELSE <other hash> ENDIF sort of
370 2019-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 :)
371 2019-11-05T19:54:10  <luke-jr> I thought it was jl
372 2019-11-05T19:54:30  <sipa> oh, this was years earlier
373 2019-11-05T19:54:32  <digi_james> Ok, so in that case the tree did encode syntax ...
374 2019-11-05T19:54:44  <digi_james> Sorry - thanks for the history lesson :)
375 2019-11-05T19:54:46  <instagibbs> russel -> jeremyrubin -> jl/maaku -> etc
376 2019-11-05T19:54:56  <instagibbs> anyways not important...
377 2019-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 :)
378 2019-11-05T19:56:01  <gmaxwell> just retcon the term to be a "merkelized arbritary script tree"
379 2019-11-05T19:56:24  <sipa> 11:52:40 <@aj> digi_james: "merklized alternative script tree" :)
380 2019-11-05T19:56:29  <andytoshi> merkleized arbitrary structure of things ;)
381 2019-11-05T19:56:40  <ariard> but what bip-taproot doesn't hold as features compare to previous MAST proposals?
382 2019-11-05T19:57:03  <ariard> on the high-level without getting into details
383 2019-11-05T19:57:03  <andytoshi> ariard: ability to access the root (or other hashes) from within script is one
384 2019-11-05T19:57:11  <sipa> ariard: there was an earlier proposal that supported multiple tree leaves simultaneously
385 2019-11-05T19:57:13  <luke-jr> ariard: it's a merkle tree, but not of AST components
386 2019-11-05T19:57:26  *** pinheadmz has quit IRC
387 2019-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
388 2019-11-05T19:57:51  <ariard> andtyoshi: recursively executing another tree committed in one of the key included in a script?
389 2019-11-05T19:57:53  <sipa> (to the best of my knowledge)
390 2019-11-05T19:58:05  <andytoshi> ariard: yeah
391 2019-11-05T19:58:21  <andytoshi> so like, you can't (efficiently) use taproot to implement keytrees in some cases
392 2019-11-05T19:58:30  <andytoshi> like if you want to check 3 keytrees in a row or something
393 2019-11-05T19:58:38  <ariard> sipa: could we execute multiple tapscript with a future taproot upgrade ?
394 2019-11-05T19:58:40  <digi_james> ariard: Thinking of it, that seems pretty cool.
395 2019-11-05T19:58:43  <andytoshi> you can't just do <root> OP_CHECKSIG <root 2> OP_CHECKSIG etc
396 2019-11-05T19:58:55  <ariard> like leaf A || leaf B || leaf D
397 2019-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
398 2019-11-05T19:59:16  <andytoshi> well, the choice that taproot makes has the nice property that it minimizes design surface
399 2019-11-05T19:59:21  <gmaxwell> andytoshi: or if you have a bag of keys and want to yank out multiple leaves.
400 2019-11-05T19:59:22  <andytoshi> which makes consensus easier to get :)
401 2019-11-05T19:59:32  <andytoshi> gmaxwell: ah yeah!
402 2019-11-05T19:59:37  <ariard> sipa: not with some kind of tail-call semantic or weird pubkey type?
403 2019-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?
404 2019-11-05T19:59:49  <ariard> a bit hacky
405 2019-11-05T19:59:50  <digi_james> Hm, are there any advantages having multiple "roots" in a tapscript to vs just separate leafs?
406 2019-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?
407 2019-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
408 2019-11-05T20:00:31  <sipa> instagibbs: because it has literally zero downsides :)
409 2019-11-05T20:00:52  <instagibbs> sipa, well, I can make some painfully obtuse design decisions otherwise ;)
410 2019-11-05T20:01:18  <instagibbs> fair enough
411 2019-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)
412 2019-11-05T20:01:29  <sipa> it is easily possible as a script
413 2019-11-05T20:01:31  <gmaxwell> sipa: outlawed and or how it interacts with bech32.
414 2019-11-05T20:01:47  <sipa> gmaxwell: yeah
415 2019-11-05T20:01:54  <sipa> oh, bad example
416 2019-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.
417 2019-11-05T20:02:18  <aj> sipa: officially overtime now, shall we stop meetbot logging and leave it for regular chatting?
418 2019-11-05T20:02:23  <sipa> yeah
419 2019-11-05T20:02:26  <aj> #endmeeting
420 2019-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)
421 2019-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
422 2019-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
423 2019-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
424 2019-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
425 2019-11-05T20:02:29  <digi_james> gmaxwell: Right .. thank you
426 2019-11-05T20:02:30  <jonatack> sipa: iirc there are 3 changes/todos in this discussion
427 2019-11-05T20:02:43  <moneyball> thank you to everyone for great participation!
428 2019-11-05T20:02:44  <kabaum> sipa: from our point of view, yes, unless question 5/8 is considered semantics.
429 2019-11-05T20:02:54  <kabaum> Thank you sooo much for your time, btc gurus. Love, group 5.
430 2019-11-05T20:03:09  <sipa> but with a way to prove multiple branches simultaneously, it would be significantly simpler
431 2019-11-05T20:03:21  <aj> kabaum: great questions
432 2019-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/
433 2019-11-05T20:03:30  <sipa> kabaum: what was 5/8 ?
434 2019-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!
435 2019-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?
436 2019-11-05T20:03:54  <sipa> jonatack: right, i meant semantical discussions; not just improvements to the writeup
437 2019-11-05T20:04:00  <sipa> kabaum: oh, agree
438 2019-11-05T20:04:11  <sipa> we can improve the actual suggested approach there
439 2019-11-05T20:04:23  <jonatack> all good
440 2019-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.
441 2019-11-05T20:04:51  <bjarnem> gmaxwell: Could you briefly explain why "[..] you should bubble up a more restrictive policy higher in your tree"?
442 2019-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
443 2019-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...
444 2019-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.
445 2019-11-05T20:06:27  <hebasto> sipa: thanks
446 2019-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
447 2019-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
448 2019-11-05T20:06:38  <gmaxwell> if they happen to be online.
449 2019-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
450 2019-11-05T20:07:11  <instagibbs> yes you'd just do k-of-k leaves
451 2019-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
452 2019-11-05T20:07:56  <bjarnem> gmaxwell: ah, I see now, gotcha!
453 2019-11-05T20:07:59  <hebasto> sipa: i thought SHA256 *transform* refers to tagged hash...
454 2019-11-05T20:08:15  <instagibbs> sipa, interested, just throw it my way
455 2019-11-05T20:08:51  *** pglazman has quit IRC
456 2019-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
457 2019-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
458 2019-11-05T20:10:13  <sipa> though i believe those to be rare
459 2019-11-05T20:10:14  <digi_james> sipa: Right - would be cool though :)
460 2019-11-05T20:10:59  <bjarnem> thanks all for this nice session! see you next time!
461 2019-11-05T20:11:02  *** bjarnem has left ##taproot-bip-review
462 2019-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 ...).
463 2019-11-05T20:12:19  <sipa> yes
464 2019-11-05T20:12:32  <sipa> thank you for all the valuable input
465 2019-11-05T20:13:43  <soju> thank you all!
466 2019-11-05T20:13:58  <digi_james> Thank you, bb
467 2019-11-05T20:14:38  <cdecker> Thanks for organizing ^^
468 2019-11-05T20:22:29  <kabaum> Thank you!
469 2019-11-05T20:25:22  <xoyi-> Thanks, bye all!
470 2019-11-05T20:28:32  *** notmandatory has joined ##taproot-bip-review
471 2019-11-05T20:31:08  *** achow101 has joined ##taproot-bip-review
472 2019-11-05T20:32:28  *** ajonas has joined ##taproot-bip-review
473 2019-11-05T20:34:22  *** andytoshi has quit IRC
474 2019-11-05T20:36:20  *** jonatack has quit IRC
475 2019-11-05T20:36:34  *** xoyi- has quit IRC
476 2019-11-05T20:38:40  *** devrandom has joined ##taproot-bip-review
477 2019-11-05T20:39:38  *** devrandom has quit IRC
478 2019-11-05T20:42:33  *** devrandom has joined ##taproot-bip-review
479 2019-11-05T20:43:06  *** soju__ has joined ##taproot-bip-review
480 2019-11-05T20:43:28  *** soju__ is now known as soju_
481 2019-11-05T20:51:39  *** Moller40_ has joined ##taproot-bip-review
482 2019-11-05T20:54:58  *** andytoshi has joined ##taproot-bip-review
483 2019-11-05T20:55:41  *** Moller40 has quit IRC
484 2019-11-05T21:01:06  *** jonatack has joined ##taproot-bip-review
485 2019-11-05T21:08:46  *** soju has quit IRC
486 2019-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:
487 2019-11-05T21:21:37  <digi_james> (A|B|C|D) & (E|F|G|H) & (I|J|K|L) & (M|N|O|P)
488 2019-11-05T21:21:49  <digi_james> With tapscript “merklescriptverify” opcodes: (2*4+1) * 32B = 9 * 32B proof (exact)
489 2019-11-05T21:21:56  <digi_james> Without (using single pk tapleafs): 4*4*4*4 = 256 leafs,  8 * 32B proof (exact)
490 2019-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
491 2019-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)
492 2019-11-05T21:23:15  <sipa> if you can expand it out, thr taproot merkle tree is perfect
493 2019-11-05T21:23:31  <digi_james> I must be missing something. Intuitively, the proof sizes grow O(log n) in both cases...
494 2019-11-05T21:23:31  <sipa> but say there are 2^64 combinations, that'd not possoblr
495 2019-11-05T21:23:53  <sipa> *that's not possible
496 2019-11-05T21:25:08  <digi_james> Such as (1/2)&(1/2)&(1/2) .. x 64?
497 2019-11-05T21:25:30  <sipa> yes, but that example isn't easy with merkle trees either
498 2019-11-05T21:26:06  <sipa> but say (1 of 64) and (1 of 64) and (1 of 64) and ...
499 2019-11-05T21:26:17  <digi_james> Hm ...
500 2019-11-05T21:26:19  <sipa> until you have billions of combinations
501 2019-11-05T21:27:11  <digi_james> so it would be <root of 64> "merklescriptverify" and <root of 64> "merklescriptverify" and ...etc.
502 2019-11-05T21:27:17  <sipa> right
503 2019-11-05T21:27:45  <sipa> it's even better if you want to do something like (4 of 64) and (4 of 64) and ...
504 2019-11-05T21:28:06  <sipa> if your merkle verify opcode supports multiple branches simultaneously
505 2019-11-05T21:28:32  <felixweis> i would also be interested in reading up on that g'root writeup
506 2019-11-05T21:28:39  <digi_james> right ...
507 2019-11-05T21:29:27  <digi_james> Is this part of graftroot? I am not sure.
508 2019-11-05T21:29:42  <sipa> digi_james: no, completely unrelated
509 2019-11-05T21:30:11  <nickler> g'root was mentioned on the mailing list? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html
510 2019-11-05T21:30:24  <sipa> nickler: yes
511 2019-11-05T21:30:51  <digi_james> nickler: Thanks a lot!
512 2019-11-05T21:30:56  <sipa> digi_james: graftroot is very different from g'root, and both are unrelated to merkle branch verify
513 2019-11-05T21:31:14  <felixweis> yes sorry for derailing
514 2019-11-05T21:31:25  <felixweis> im just reading up on tapscript and the versioning
515 2019-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
516 2019-11-05T21:33:25  <sipa> sure
517 2019-11-05T21:33:28  <sipa> in theiry
518 2019-11-05T21:33:30  <sipa> theory
519 2019-11-05T21:34:07  <felixweis> to clarify, without sending it to a new ouput first
520 2019-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
521 2019-11-05T21:35:23  <sipa> but that's a lot of hypotheticals
522 2019-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.
523 2019-11-05T21:40:14  <sipa> digi_james: again, i'm talking about a situation where you simply cannot expand it out
524 2019-11-05T21:40:26  <sipa> as i said, if you can expand it, the taproot merkle tree is perfect
525 2019-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
526 2019-11-05T21:42:37  <digi_james> Oh I see.  Why would it not be possible to expand any script with OR's?
527 2019-11-05T21:43:30  <sipa> because say if there are say 2^64 combinations it's just computationally intractable to compute the address
528 2019-11-05T21:43:40  <sipa> let alone sign for it
529 2019-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.
530 2019-11-05T22:03:09  <sipa> digi_james: you simply cannot even iterate over 2^64 branches, let alone do 2^64 musig aggregations
531 2019-11-05T22:03:15  <sipa> i mean, you can
532 2019-11-05T22:03:29  <digi_james> right ... :)
533 2019-11-05T22:04:22  <sipa> but there is some point where it simply goes from impractical to pointless
534 2019-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?
535 2019-11-05T22:08:32  <digi_james> "merkleverify"
536 2019-11-05T22:09:15  <sipa> the reason it's not in there is that it can be done independently with no downside
537 2019-11-05T22:10:35  <digi_james> another softfork?
538 2019-11-05T22:11:01  <sipa> yes, if you like
539 2019-11-05T22:11:35  <sipa> i mean, we have op_success for a reason, right
540 2019-11-05T22:11:53  <digi_james> :)
541 2019-11-05T22:12:41  <sipa> or not
542 2019-11-05T22:12:44  <sipa> that's the point
543 2019-11-05T22:12:57  <sipa> whether this is desirable should be an independent discussion
544 2019-11-05T22:13:17  <sipa> and the nice thing is that doing it independently has no downside
545 2019-11-05T22:17:48  *** b10c has quit IRC
546 2019-11-05T22:18:03  *** pglazman has joined ##taproot-bip-review
547 2019-11-05T22:19:19  <digi_james> sipa: Thank you!
548 2019-11-05T22:27:38  *** michaelfolkson has joined ##taproot-bip-review
549 2019-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.
550 2019-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.
551 2019-11-05T22:36:53  <sipa> right, tree depth is roughly proportional to the log2(1/probability) of the least-probable script in your tree
552 2019-11-05T22:37:05  <sipa> but what we're talking about here is tree *size*, not depth
553 2019-11-05T22:40:00  *** jeremyrubin has joined ##taproot-bip-review
554 2019-11-05T22:40:51  *** Chris_Stewart_5 has quit IRC
555 2019-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
556 2019-11-05T22:48:00  *** Lexyon__ has joined ##taproot-bip-review
557 2019-11-05T22:48:14  <digi_james> or complexity resulting from (very large) option count i should say.
558 2019-11-05T22:48:17  *** stacie has quit IRC
559 2019-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.
560 2019-11-05T22:48:50  <digi_james> :
561 2019-11-05T22:48:51  <gmaxwell> (20 choose 10 is roughly 2^17.5)
562 2019-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.
563 2019-11-05T22:50:23  <sipa> especially now that the script size/sigops limits have been removed/relaxed
564 2019-11-05T22:50:57  <sipa> before you could argue that many policies (albeit unusual/uninteresting ones) were actually impossible to implememt as a script
565 2019-11-05T22:51:14  <sipa> now they're merely more costly to fully deal with
566 2019-11-05T22:52:28  <gmaxwell> Whats the operative standardness limit on the number of checksigadds?
567 2019-11-05T22:53:13  <sipa> 50 vbytes per sigop
568 2019-11-05T22:53:28  <sipa> ah, standardness
569 2019-11-05T22:53:33  <sipa> currengl
570 2019-11-05T22:53:44  <sipa> currently my branch has none in addition to the consensus ones
571 2019-11-05T22:54:12  <sipa> sorry, 50 wu per sigoo
572 2019-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?
573 2019-11-05T22:56:46  <sipa> right
574 2019-11-05T22:57:39  <sipa> i believe you can, though you'll start running into transaction stadardness limits
575 2019-11-05T22:57:47  <sipa> (400000 WU per tx)
576 2019-11-05T23:02:10  <sipa> 0 (SWAP IF <key_i> CSA ENDIF)*10000 4 EQUAL
577 2019-11-05T23:02:26  <sipa> that will implement 4-of-10000 i think
578 2019-11-05T23:03:02  <gmaxwell> I picked that number because it was under 400kWU.
579 2019-11-05T23:03:18  <gmaxwell> cool.
580 2019-11-05T23:03:36  <gmaxwell> At least then there won't be an non-efficiency reasons for people to refrain from such policies.
581 2019-11-05T23:05:15  <sipa> 380010 kWU
582 2019-11-05T23:05:21  <sipa> for the witness
583 2019-11-05T23:05:38  <sipa> -k
584 2019-11-05T23:06:41  <sipa> i should add that as a test
585 2019-11-05T23:27:47  *** Moller40_ has quit IRC
586 2019-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?
587 2019-11-05T23:30:36  <sipa> r251d: you read that right; if that it isn't clear, it's certainly worth improving
588 2019-11-05T23:30:54  <sipa> the usual terminology for those is the "merkle path" or "merkle proof"
589 2019-11-05T23:31:03  <sipa> but i don't think we're using either of those terms
590 2019-11-05T23:31:39  *** thestack has joined ##taproot-bip-review
591 2019-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.
592 2019-11-05T23:42:12  <r251d> Thanks for explaining.
593 2019-11-05T23:44:43  <sipa> Right.
594 2019-11-05T23:50:32  *** pinheadmz has joined ##taproot-bip-review
595 2019-11-05T23:51:43  *** real_or_random has joined ##taproot-bip-review
596 2019-11-05T23:54:28  *** jonatack has quit IRC
597 2019-11-05T23:58:51  *** Tibo has joined ##taproot-bip-review