1 2019-11-12T00:51:23  *** Chris_Stewart_5 has quit IRC
  2 2019-11-12T01:20:57  *** HighOnBtc has quit IRC
  3 2019-11-12T01:25:24  *** Chris_Stewart_5 has joined ##taproot-bip-review
  4 2019-11-12T02:38:03  *** Chris_Stewart_5 has quit IRC
  5 2019-11-12T07:42:47  *** jeremyrubin has joined ##taproot-bip-review
  6 2019-11-12T08:51:58  *** b10c has joined ##taproot-bip-review
  7 2019-11-12T09:04:53  *** jonatack has quit IRC
  8 2019-11-12T09:17:14  *** orfeas has joined ##taproot-bip-review
  9 2019-11-12T09:38:00  *** afk11 has quit IRC
 10 2019-11-12T09:38:00  *** mryandao has quit IRC
 11 2019-11-12T09:38:49  *** mryandao has joined ##taproot-bip-review
 12 2019-11-12T09:38:50  *** afk11 has joined ##taproot-bip-review
 13 2019-11-12T09:40:27  *** marcinja has quit IRC
 14 2019-11-12T09:43:13  *** marcinja has joined ##taproot-bip-review
 15 2019-11-12T09:45:53  *** jonatack has joined ##taproot-bip-review
 16 2019-11-12T10:10:26  *** xoyi- has joined ##taproot-bip-review
 17 2019-11-12T10:11:26  <xoyi-> sipa: would it make sense to reference BIP173 instead of BIP141 in "A Taproot output is a native SegWit output (see BIP141)", since BIP173 is more specific to that sentence?
 18 2019-11-12T10:34:57  <aj> xoyi-: 173 describes the address format (presented to users in wallets) rather than the scriptPubKey format which is what actually appears on chain, so 141 seems like a better fit
 19 2019-11-12T10:36:40  <xoyi-> ah right. Thanks for clarifying @aj
 20 2019-11-12T10:52:02  *** jeremyrubin has quit IRC
 21 2019-11-12T11:10:19  <waxwing> we (group 6) were confused about hash_type 0x00 - the taproot bip says the new tx digest has all the old sighash flags (1,2,3, +0x80) but this 0x00 seems to be a default, but it isn't explained what sighashing it refers to/defines?
 22 2019-11-12T11:10:28  <waxwing> feel like i must have missed something.
 23 2019-11-12T11:11:48  <aj> waxwing: bip-taproot "Signature validation rules" says when hash_type = 00
 24 2019-11-12T11:13:08  <waxwing> aj, yes that's what i/we read. i don't get it. what is this default value, what does it mean about sighashing? it's not the same as sighash_all (0x01), right?
 25 2019-11-12T11:13:34  <aj> waxwing: it is the same as sighash_all, except it's 64 bytes instead of 65 bytes
 26 2019-11-12T11:13:43  <waxwing> aj, ok. is that stated anywhere?
 27 2019-11-12T11:13:58  <waxwing> under 'hash_type' it says the legacy are still retained, including SIGHASH_ALL
 28 2019-11-12T11:14:34  <waxwing> so to me it was far from intuitive to infer that 0x00 had the same meaning (i felt i had to assume the opposite). again, i'm probably just being dumb :)
 29 2019-11-12T11:14:58  <aj> waxwing: i think you just have to read through the logic and see it behaves the same way?
 30 2019-11-12T11:15:40  <aj> waxwing: if you do SIGHASH_ALL | SIGHASH_ANYONECANPAY you get 0x81 but 0x80 isn't valid, which is another difference
 31 2019-11-12T11:15:59  <waxwing> aj, but where in 'Signature validation rules' does it tell you that it's ALL sighashing with 0x00?
 32 2019-11-12T11:16:24  <waxwing> it just says valid signature according to bip-schnorr and message set to transaction digest, but doesn't say which transaction digest right.
 33 2019-11-12T11:16:34  <aj> waxwing: i think rationale entry 11 is the most explicit comment.
 34 2019-11-12T11:17:08  <aj> waxwing: i meant if you read through the rules, 0x00 and 0x01 will give you the same semantics
 35 2019-11-12T11:17:34  <waxwing> well yes, it's the same thing: it was always absolutely clear that 0x00 is a default and that explains all the reasons. but i don't think that section tells you that 0x00 is a signature over the entire transaction (as sighash_all). does it?
 36 2019-11-12T11:18:45  <aj> waxwing: yeah, i think it just assumes you know which one's the most common type
 37 2019-11-12T11:19:07  <waxwing> aj, right. and that *might* be fine if it wasn't for the fact that it explicitly says 0x01 is retained as SIGHASH_ALL
 38 2019-11-12T11:19:21  <waxwing> that made me tend to discount the possibility that 0x00 was the same.
 39 2019-11-12T11:19:47  <waxwing> (point taken though about 0x80, 0x81)
 40 2019-11-12T11:20:19  <aj> waxwing: i think what you'd like to see is (a) an explicit "64-bytes sigs are SIGHASH_ALL" and (b) "why allow specifying SIGHASH_ALL as 65-bytes sig as well as 64-bytes sig?" in rationale?
 41 2019-11-12T11:21:08  <waxwing> i didn't think much about (b) tbh but perhaps. but yeah for sure (a), i am reasonably confident i am not the only reader who will be confused by that :)
 42 2019-11-12T11:21:27  <waxwing> i think one of the rationales already kinda covers (b), the one you mentioned prob.
 43 2019-11-12T11:23:05  <waxwing> on reflection i guess i was being a bit dumb .. i am sometimes too literal a reader. it would be pretty bizarre if it wasn't *ALL. but still, write it in I think.
 44 2019-11-12T11:23:23  <aj> yeah, i was surprised it's not stated
 45 2019-11-12T11:23:33  <aj> file a PR or issue?
 46 2019-11-12T11:23:59  <waxwing> so why do we still have 0x01 then? is it because of the ACP flag so you can get 0x81?
 47 2019-11-12T11:24:10  <waxwing> aj, sure i'll do it, thanks for your help
 48 2019-11-12T11:24:30  <aj> well having 0x01 matches SIGHASH_ALL as it currently exists
 49 2019-11-12T11:25:08  <waxwing> yes. not sure why that matters? new sig scheme and new digest? (so code isn't going to be the same anyway)
 50 2019-11-12T11:25:11  <aj> but you could have 64-bytes = hash_type=0x01, and not allow 0x01 in 65-byte sigs
 51 2019-11-12T11:25:27  <waxwing> yeah that's what would have felt a lot more natural
 52 2019-11-12T11:25:48  <waxwing> adding a new flag value with the same semantics as an old one, which is not removed seems weird
 53 2019-11-12T11:26:59  <aj> i think there might've been some discussion about being able to have 65-byte sig of any type so you didn't change fees, so /maybe/ there's a reason, but i certainly can't think of i tnow
 54 2019-11-12T11:36:06  <waxwing> Hmm now i read the "Transaction digest"/"Transaction data" section i see that it's been written without reference to *ALL, which makes sense - this means that you get default behaviour whether you have the 0x01 or the implicit 0x00. So technically you could argue the confusion isn't there.
 55 2019-11-12T11:36:20  <waxwing> But I'll still PR it because it's just one extra sentence and it'd avoid confusion.
 56 2019-11-12T11:43:58  <aj> waxwing: yeah, i think it's well defined, but it's not clear
 57 2019-11-12T11:47:12  *** Chris_Stewart_5 has joined ##taproot-bip-review
 58 2019-11-12T12:37:25  *** HighOnBtc has joined ##taproot-bip-review
 59 2019-11-12T12:38:03  <sosthene> Thanks aj and waxwing, it's clear now
 60 2019-11-12T12:38:58  *** evoskuil[m] has quit IRC
 61 2019-11-12T12:39:58  <sosthene> I'm curious if there are still other reasons besides having 65 byte sig of any type
 62 2019-11-12T12:40:39  <sosthene> but that alone makes sense I guess
 63 2019-11-12T12:54:57  *** Chris_Stewart_5 has quit IRC
 64 2019-11-12T12:57:05  *** Chris_Stewart_5 has joined ##taproot-bip-review
 65 2019-11-12T13:10:47  *** udiWertheimer has joined ##taproot-bip-review
 66 2019-11-12T13:11:01  *** udiWertheimer_ has left ##taproot-bip-review
 67 2019-11-12T13:27:36  *** orfeas has quit IRC
 68 2019-11-12T13:43:56  *** evoskuil[m] has joined ##taproot-bip-review
 69 2019-11-12T14:02:06  *** orfeas has joined ##taproot-bip-review
 70 2019-11-12T14:26:04  *** jonatack has quit IRC
 71 2019-11-12T14:26:19  *** jonatack has joined ##taproot-bip-review
 72 2019-11-12T14:30:08  <instagibbs> is CastToBool defined in any BIP anywhere?
 73 2019-11-12T14:32:20  <instagibbs> I know where to find the code-based definition, just seemed like something that should be defined
 74 2019-11-12T14:35:06  <instagibbs> "called the tapscript and is decoded into opcodes, one by one" the context and footnotes make this more clear, but I think it should stress that this is not during script execution
 75 2019-11-12T14:42:26  <instagibbs> joke observation: if we ever get to gigameg blocks, we'll need to define what happens to `codeseparator_position` after 2^32 bytes.
 76 2019-11-12T14:47:57  *** pinheadmz has quit IRC
 77 2019-11-12T14:51:50  *** jonatack has quit IRC
 78 2019-11-12T15:02:22  *** HighOnBtc has quit IRC
 79 2019-11-12T15:10:31  <orfeas> compact_size() and CCompactSize are not defined in the 3 bips. Should there be a link to their definition?
 80 2019-11-12T15:23:14  *** xoyi- has quit IRC
 81 2019-11-12T15:54:51  *** orfeas has quit IRC
 82 2019-11-12T15:56:58  *** orfeas has joined ##taproot-bip-review
 83 2019-11-12T16:00:22  <waxwing> sosthene, oh i see, you mean like, you could always know the size is the same whatever type of signing you do. that seems pretty artificial to me. oh well, shrug, it's not a huge deal i guess.
 84 2019-11-12T16:07:06  <elichai2> orfeas: well AFAIK they're not defined anywhere. it's an implementation detail
 85 2019-11-12T16:09:02  <orfeas> elichai2: isn't it consensus-critical though?
 86 2019-11-12T16:10:05  <orfeas> I guess they are defined as in the reference implementation then
 87 2019-11-12T16:10:12  <elichai2> orfeas: the consensus code is very far from being properly defined
 88 2019-11-12T16:10:21  <elichai2> (outside of Core itself obviously)
 89 2019-11-12T16:11:50  <orfeas> would a footnote with a link to the relevant Core function make sense? or this opens a whole new can of worms?
 90 2019-11-12T16:15:03  *** jenseven has joined ##taproot-bip-review
 91 2019-11-12T16:16:46  <elichai2> that would be inconsistent with other PRs. i.e. https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
 92 2019-11-12T16:19:47  <orfeas> thanks. one more question: why is "compact_size(size of s)" in "hashTapLeaf(l || compact_size(size of s) || s)"? To avoid length extension attacks?
 93 2019-11-12T16:21:35  <elichai2> because in bitoin core when you serialize a CScript you get Bytes((CCompactSize(script) || script))
 94 2019-11-12T16:22:26  <elichai2> a rule of thumb, if you see CCompactSize asusme it's an implementation detail :)
 95 2019-11-12T16:22:44  <elichai2> (and when there are no private data fields assume length extension attacks aren't interesting :) )
 96 2019-11-12T16:27:10  <elichai2> instagibbs: pretty sure `CastToBool` isn't defined outside of the codebase
 97 2019-11-12T16:29:37  <sipa> aj, waxwing hash type 0 is different from 1 simply to prevent malleating 64 byte sigs into 65 byte ones; they're otherwise identical in semantics
 98 2019-11-12T16:30:17  <sipa> they also match the current semantics where both 0 and 1 are valid hashtypes that correspond to SIGHASH_ALL
 99 2019-11-12T16:31:26  <waxwing> oh right you couldn't avoid that if you had 0x01 as hash_type in the default case, but now since it's covered by the digest algo you avoid having a 65 byte version valid where a 64 byte was created.
100 2019-11-12T16:32:11  <waxwing> second sentence i didn't get, you're not saying 0x00 is a valid sighash byte currently?
101 2019-11-12T16:32:51  <sipa> currently (in legacy and segwit v0) 0 is a valid sighash type
102 2019-11-12T16:32:59  <sipa> with the same semantics as ALL
103 2019-11-12T16:33:17  *** arik_ has quit IRC
104 2019-11-12T16:33:29  <waxwing> oh i had no idea. is that ever used?
105 2019-11-12T16:35:32  <sipa> maybe a better way of stating is that the only valid sighash types are 1-3 and 81-83, while 64 byte sigs implicitly behave the same as ALL, but use 0 as sighash value in the sighash algorithm to prevent malleability
106 2019-11-12T16:35:42  <sipa> waxwing: i doubt it
107 2019-11-12T16:36:55  *** jonatack has joined ##taproot-bip-review
108 2019-11-12T16:37:02  <waxwing> weird. a big cause of my confusion was no doubt that i had never heard of that, nor seen it used. (but i'd still argue for adding some small note that clarifies.)
109 2019-11-12T16:39:19  <sipa> agreed
110 2019-11-12T16:43:17  <jonatack> instagibbs: was disconnected so this may be out of band, AFAIK CastToBool is only mentioned in bip-0141.mediawiki:107, and not defined
111 2019-11-12T16:52:27  <sipa> it's implicitly defined by the source code, but i think it's worth spelling out exactly
112 2019-11-12T17:16:48  <jonatack> src/script/interpreter.cpp:35:bool CastToBool(const valtype& vch)
113 2019-11-12T17:24:54  *** orfeas has quit IRC
114 2019-11-12T17:36:18  *** Chris_Stewart_5 has quit IRC
115 2019-11-12T17:46:44  *** bjarnem has joined ##taproot-bip-review
116 2019-11-12T17:54:48  *** Chris_Stewart_5 has joined ##taproot-bip-review
117 2019-11-12T18:00:49  *** pyskell has quit IRC
118 2019-11-12T18:01:57  <jnewbery> Hi folks. Next Q&A starts in one hour
119 2019-11-12T18:22:56  *** jeremyrubin has joined ##taproot-bip-review
120 2019-11-12T18:23:36  <jonatack> Q: where does the Python code in bip-taproot live? Aside from the function taproot_tree_helper, which I see a (different version of) in test/functional/test_framework/script.py, I'm not seeing the other code.
121 2019-11-12T18:24:06  <jonatack> (grepping in the taproot branch of sipa/bitcoin)
122 2019-11-12T18:24:29  <sipa> jonatack: all the "signing" code is in feature_taproot.py
123 2019-11-12T18:24:36  <sipa> some of it can probably be abstracted out
124 2019-11-12T18:29:43  <jonatack> sipa: ty. bip-taproot states "the output script can be computed using the following Python3 algorithms with helper functions from the bip-schnorr reference code"
125 2019-11-12T18:30:16  <jonatack> perhaps a link... I don't see most of that code (as named)
126 2019-11-12T18:32:34  <sipa> jonatack: oh! that's referring to https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py
127 2019-11-12T18:32:38  <sipa> not the bitcoin core branch
128 2019-11-12T18:32:51  <sipa> i think?
129 2019-11-12T18:33:32  *** pyskell has joined ##taproot-bip-review
130 2019-11-12T18:33:32  *** pyskell has joined ##taproot-bip-review
131 2019-11-12T18:35:16  <jonatack> hm! will pull down sipa/bips to grep it
132 2019-11-12T18:40:54  <jonatack> no dice, for instance `git grep -ni taproot_tweak` only returns results in https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
133 2019-11-12T18:41:53  <sipa> what specific function are you missing?
134 2019-11-12T18:42:00  <sipa> or what reference is unexplained?
135 2019-11-12T18:44:15  <jonatack> I was looking for where the code presented in bip-taproot lives, e.g. the functions taproot_tweak_*, taproot_sign_*, taproot_output_script
136 2019-11-12T18:44:31  <sipa> they're in the bip?
137 2019-11-12T18:44:42  <jonatack> Yes, only in the bip
138 2019-11-12T18:44:59  <sipa> ah, you mean is there some python file you can use directly? no
139 2019-11-12T18:45:02  <sipa> perhaps there should be
140 2019-11-12T18:45:52  <jonatack> Thought it might be extracted from elsewhere as it was described as the Python3 "bip-schnorr reference code"
141 2019-11-12T18:46:22  <jonatack> (in bip-taproot)
142 2019-11-12T18:46:41  <sipa> the bip-schnorr reference code is https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py
143 2019-11-12T18:46:48  <sipa> there is no similar thing for bip-taproot
144 2019-11-12T18:47:22  <jonatack> ty for the clarification
145 2019-11-12T18:47:24  <sipa> we probably want to have that when writing test vectors for taproot
146 2019-11-12T18:49:06  *** pinheadmz has joined ##taproot-bip-review
147 2019-11-12T18:55:56  *** Moller40 has joined ##taproot-bip-review
148 2019-11-12T18:57:37  <jonatack> ok. will pr to make the sentence clear that the helper functions, and not the example code, are from the bip-schnorr reference code with a link to reference.py
149 2019-11-12T18:57:57  <sipa> ok
150 2019-11-12T19:00:00  <moneyball> Q&A about to start...
151 2019-11-12T19:00:06  <jnewbery> ...
152 2019-11-12T19:00:15  <aj> #startmeeting
153 2019-11-12T19:00:15  <lightningbot> Meeting started Tue Nov 12 19:00:15 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
154 2019-11-12T19:00:15  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
155 2019-11-12T19:00:17  <jnewbery> hi
156 2019-11-12T19:00:20  <sipa> hi
157 2019-11-12T19:00:20  <bjarnem> hi
158 2019-11-12T19:00:40  <schmidty> Hi
159 2019-11-12T19:00:43  <moneyball> hi
160 2019-11-12T19:00:44  <r251d> hi
161 2019-11-12T19:00:49  <ariard> hi
162 2019-11-12T19:00:54  <jonatack> hi
163 2019-11-12T19:01:00  <devrandom> hi
164 2019-11-12T19:01:31  <kabaum> hi
165 2019-11-12T19:01:31  <aj> hi
166 2019-11-12T19:01:31  <hebasto> hi
167 2019-11-12T19:02:15  <cdecker> Hi
168 2019-11-12T19:02:19  <hebasto> Q from group 5 (1/2): 1. What happens when using other leaf versions now before they are defined?
169 2019-11-12T19:02:48  <fjahr> hi
170 2019-11-12T19:03:11  *** michaelfolkson has joined ##taproot-bip-review
171 2019-11-12T19:03:22  <sipa> hebasto: they're spendable by anyone (who can give the internal key and merkle path)
172 2019-11-12T19:03:51  <bjarnem> I was having the same question and I don't think this is specified in the BIP.
173 2019-11-12T19:04:05  <sipa> bjarnem: it is, i think, though not explicitly
174 2019-11-12T19:04:19  <hebasto> yes, it is not obvious from bip...
175 2019-11-12T19:04:27  <sipa> bip-taproot just states that any relevant scripts are executed
176 2019-11-12T19:04:43  <jnewbery> would those spends be non-standard initially?
177 2019-11-12T19:04:48  <sipa> jnewbery: of course
178 2019-11-12T19:04:49  <kabaum> I think taproot rationale [10] is what we're looking for,
179 2019-11-12T19:04:58  <pyskell> hi
180 2019-11-12T19:05:03  *** arik_ has joined ##taproot-bip-review
181 2019-11-12T19:05:07  <sipa> bip-tapscript defines one for one particular leaf version
182 2019-11-12T19:05:10  *** jenseven has quit IRC
183 2019-11-12T19:05:21  <aj> sipa: "of course" -- should it be written down somewhere which bits should be treated as non-standard?
184 2019-11-12T19:05:42  <jnewbery> I think standardness falls outside the BIPs, which only deal with consensus, no?
185 2019-11-12T19:05:42  <sipa> perhaps we can add that if no script semantics are defined for a particular leaf version, the spend is unconditionally valid
186 2019-11-12T19:05:48  *** KeithMukai has joined ##taproot-bip-review
187 2019-11-12T19:05:52  <sipa> jnewbery: yeah, that's my thinking
188 2019-11-12T19:05:53  <Moller40> Hi
189 2019-11-12T19:06:23  <cdecker> That'd be a nice addition
190 2019-11-12T19:06:45  <sipa> aj: it feels strange to specify standardness rules in these bips, as they're far less "everyoneust agree on this" than the consensus parts
191 2019-11-12T19:06:52  <aj> treating things as non-standard is important for future soft-forks to be safe (so that nodes that don't validate the new rules dont relay new tx's that might violate them) though?
192 2019-11-12T19:07:04  <sipa> but i also see that it'd be nice to have it written up somewhere
193 2019-11-12T19:07:18  <aj> sipa: yeah, agree on both points :)
194 2019-11-12T19:08:04  <hebasto> Q from group 5 (2/2). Disabled script opcodes."unexecuted branch" means unexecuted branch in the revealed script?
195 2019-11-12T19:08:05  *** sergei-t has joined ##taproot-bip-review
196 2019-11-12T19:08:18  <sipa> hebasto: correct
197 2019-11-12T19:08:26  <hebasto> sipa; ty
198 2019-11-12T19:08:27  <sipa> i see how branch can be confusing here
199 2019-11-12T19:08:45  <hebasto> a bit ;)
200 2019-11-12T19:08:49  <sipa> it means execution branch of the script, not merkle branch
201 2019-11-12T19:09:08  <cdecker> Related: aborting when decoding the script instead of executing is merely a performance improvement, or am I missing something?
202 2019-11-12T19:09:33  <hebasto> maybe "execution branch" and "merkle branch" are good wording for bip?
203 2019-11-12T19:10:09  <sipa> cdecker: it also implies that any later success isn't apllicable
204 2019-11-12T19:10:17  <sipa> hebasto: sure
205 2019-11-12T19:10:23  <bjarnem> Q: Regarding the tweak value `t` must be less than the SECP256K1_ORDER: What to do if the calculated value is greater/equal?
206 2019-11-12T19:10:33  <sipa> bjarnem: it won't be
207 2019-11-12T19:10:44  <jnewbery> bjarnem: buy a lottery ticket
208 2019-11-12T19:10:47  <cdecker> Right, but it allows statically discarding things early on, without having to execute
209 2019-11-12T19:11:25  <sipa> cdecker: if your question is whether you can write an alternative way to interpreting that does not actually return false immediately upon abort, of course
210 2019-11-12T19:12:05  <sipa> but abort in this context is more than giving a suggested optimization for implementers; it's stating that if that condition is reached, the script must fail
211 2019-11-12T19:12:44  <pyskell> The Taproot BIP says:  "To the best of the authors' knowledge, no existing use of SHA256 in Bitcoin feeds it a message that starts with two single SHA256 outputs, making collisions between hashtag with other hashes extremely unlikely." What is meant by it and what would happen if it's true? Mostly interested because it's stated in somewhat uncertain terms.
212 2019-11-12T19:12:44  <cdecker> Yep, just felt strange to abort on a script branch that isn't even executed :-)
213 2019-11-12T19:13:02  *** michaelfolkson has quit IRC
214 2019-11-12T19:13:11  <sipa> cdecker: i see
215 2019-11-12T19:13:28  <bjarnem> Q: Regarding the squareness of `Q`: (Disclaimer: I am not a cryptographer, so I hope this question is not naive)
216 2019-11-12T19:13:28  <bjarnem> I am unsure regarding the necesity of using a bit to indicate the `has_square_y(Q)` in the control block (Ad7 and Ad6 explain that the squareness of y cannot be guaranteed for `Q`).
217 2019-11-12T19:13:28  <bjarnem> The `Q` value (tweaked pubkey) is commited as scriptPubKey. It can hence also be spend using the key path with a Schnorr signature. But BIP-Schnorr then requires the (tweaked) pubkey `Q` to pass `has_square_y(Q)`. Shouldn't it therefore be guaranteed that for `Q` such a y-coord exists? Or am I misunderstanding something completely?
218 2019-11-12T19:14:05  *** michaelfolkson has joined ##taproot-bip-review
219 2019-11-12T19:14:17  <sipa> cdecker: not sure how to formulate more clearly... you can see it as a preprocessing step of executing the script (in which case it's just a failure rather than aborting during execution itself
220 2019-11-12T19:15:16  <cdecker> The formulation is clear, I was just wondering about the rationale. All good, don't want to hold up the QA ^^
221 2019-11-12T19:15:23  <nickler> bjarnem: for key spending Q doesn't have a y coordinate. So the verifier will choose the y coordinate that is square (there's only two options).
222 2019-11-12T19:15:27  <sipa> bjarnem: when spending using the key path, you interpret Q as a has_square point, regardlesz of how it was constructed, and sign possibly with its negation
223 2019-11-12T19:15:34  <pyskell> Is it referring to the SHA256 opcode or something else?
224 2019-11-12T19:15:59  <sipa> bjarnem: when signing using the script path, you have to actually know the squaredness of Y, otherwise the commitment equation won't hold
225 2019-11-12T19:16:20  <jnewbery> One thing that we spent a bit of time talking about in our group session was the annex. Both the format (ie starting with 0x50) and the purpose.
226 2019-11-12T19:16:30  <jnewbery> For the format, I think we explicitly want a leading byte that can't be interpreted as a pubkey (so it can't be confused for P2WPKH) or a opcode (so it can't be confused for P2WSH). 0x50 fits the bill because it can't be a pubkey leading byte (which must be 0x02 or 0x03) and it's an invalid opcode (defined as OP_RESERVED internally, but with unconditional fail semantics).
227 2019-11-12T19:16:45  <aj> sipa, bjarnem: and you can't just try both options if we want to batch verify to make it more efficient
228 2019-11-12T19:17:26  <sipa> jnewbery: it's stronger than that! you can recognize an annex in an input without knowing which output is being spent
229 2019-11-12T19:17:27  <jnewbery> citation 3: https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#cite_note-3 explains that briefly, but I think it could be expanded a bit (I had to dig around to find 0x50 in script/interpreter.cpp
230 2019-11-12T19:17:39  <sipa> jnewbery: which is by design
231 2019-11-12T19:17:40  <bjarnem> sipa: ok, I see, so for the script path it is important to show exactly which point, and the x-coord is not enough. I will try to read up on that to understand it a little better :)
232 2019-11-12T19:18:13  <jnewbery> right. What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent?
233 2019-11-12T19:18:14  <sipa> bjarnem: feel free to PR a clarification if you find text that would make it easier to understand for you
234 2019-11-12T19:18:46  <sipa> jnewbery: did you get the idea of using an annex to artifically increase an input's weight?
235 2019-11-12T19:19:10  <jnewbery> I understood the purpose, but wondered why you couldn't just do that in the tapscript
236 2019-11-12T19:19:21  <sipa> ?
237 2019-11-12T19:19:51  <sipa> oh you mean by putting a big push + OP_DROP in the script?
238 2019-11-12T19:20:24  <jnewbery> I think the idea is that if we redefine an OP_SUCCESS to be something like OP_VERIFYSNARK, then we want to increase the weight becuase of the increased validation cost
239 2019-11-12T19:20:42  <jnewbery> yes, why not just add that weight to the script
240 2019-11-12T19:20:57  <sipa> jnewbery: that seems.like highly inefficient use of the chain
241 2019-11-12T19:21:17  <sipa> if you need to pad it with garbage
242 2019-11-12T19:21:28  <jnewbery> isn't that what the annex is doing?
243 2019-11-12T19:21:31  <bjarnem> Q: What is reasoning behind OP_SUCCESSx instead of only using the available versioning fields to soft-fork new Tapscript logic into the system (e.g. using the leaf version)?
244 2019-11-12T19:21:32  <ariard> can't it be used also for a per-input locktime IIRC ?
245 2019-11-12T19:21:35  <sipa> jnewbery: no!
246 2019-11-12T19:21:46  <jnewbery> oh, then I misunderstand!
247 2019-11-12T19:22:28  <sipa> jnewbery: the idea would be for example that an annex whose first byte (after the 0x50, using some encoding) is 0x37, a 2-byte field follows
248 2019-11-12T19:22:47  <sipa> and the value of that two byte field is added to the weight of the tx
249 2019-11-12T19:23:15  <sipa> while simultaneously equivalently increasing the budget for expensivw opcodes in tbe script
250 2019-11-12T19:23:36  <sipa> ariard: for examlle
251 2019-11-12T19:23:49  <sipa> ariard: or a block height hash requirement
252 2019-11-12T19:23:55  <ariard> sipa: yes but the value of that two byte can be choosed by the spender how would you make it mandatory ?
253 2019-11-12T19:24:21  <sipa> ariard: if they set it tol high, they'll pay extra fees
254 2019-11-12T19:24:22  <jnewbery> after this imaginary future OP_VERIFYSNARK softfork, are unupgraded miners still able to mine? How do they account block weight?
255 2019-11-12T19:24:29  <ariard> don't you need to combine with some sighash flags to force annex value being covered by transaction digest
256 2019-11-12T19:24:35  <sipa> of they set it too low, the script will fail
257 2019-11-12T19:24:37  <aj> ariard: if you spend more computation than the budget, your tx is invalid; so to increase the budget, you put the smallest value you can into the annex
258 2019-11-12T19:24:54  <sipa> ariard: annexes are always covered by signatures
259 2019-11-12T19:24:58  <hebasto> sipa: annex could increase weight without bloating chain, right?
260 2019-11-12T19:25:04  <sipa> hebasto: right
261 2019-11-12T19:25:17  <sipa> jnewbery: increasing the weight for a transaction is a softfork
262 2019-11-12T19:25:32  <sipa> and using an unknown annex is nonstandard
263 2019-11-12T19:25:41  <sipa> so i think this is perfectly possible to deploy
264 2019-11-12T19:25:59  <sipa> (that doesn't mean we need to; there may never be a reason to)
265 2019-11-12T19:26:11  <ariard> aj: okay so it means we track budget during script evaluation and if committed budget in annex doesn't match it's a failure ?
266 2019-11-12T19:26:13  <jnewbery> unupgraded miners just don't include anything with an annex because it's non-standard?
267 2019-11-12T19:26:18  <sipa> right
268 2019-11-12T19:26:45  <sipa> ariard: the budget is the size of the input, which if amended by an annex, includes that amount
269 2019-11-12T19:27:07  <waxwing> wait surely we expect miners to upgrade in SF scenarios to avoid mis-mining?
270 2019-11-12T19:27:27  <nickler> sipa: with op_zkverify would the limit be something like #(OP_CHECKSIG)*50 + #(OP_ZKVERIFY)*X <= weight?
271 2019-11-12T19:27:35  <sipa> nickler: exactly
272 2019-11-12T19:27:36  <ariard> sipa: and you check the budget against which reference value ? that's where I choke
273 2019-11-12T19:27:49  <sipa> ariard: the weight of the input
274 2019-11-12T19:28:04  <sipa> right now that is literally the number of bytes of the witness
275 2019-11-12T19:28:24  <sipa> if an annex is defined that increments the weight, that counts too
276 2019-11-12T19:28:40  <elichai2> nickler: op_zkverify?
277 2019-11-12T19:28:56  <moneyball> elichai2: a hypothetical example
278 2019-11-12T19:29:34  <jnewbery> What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent?
279 2019-11-12T19:29:57  <sipa> jnewbery: for this annex weight increase example it's useful
280 2019-11-12T19:30:17  <sipa> as otherwise you wouldn't be able to compute a tx's weight without access to the output being spent
281 2019-11-12T19:30:53  <devrandom> group 3 Q 1/?: "The total number of bytes hashed is at most 211" - this doesn't include the sub-hashes, like computing sha_prevouts, etc., right?  the reason sub-hashes are not included in the 211 bytes is because they can be cached across sigs for the same tx?
282 2019-11-12T19:31:09  <sipa> devrandom: exactly
283 2019-11-12T19:31:19  <elichai2> moneyball: :) I thought we're already planning tapscript V2 :P
284 2019-11-12T19:31:44  <devrandom> maybe that sentence can be expanded to mention the sub-hashes?  I can PR?  or do you think it's clear enough as is?
285 2019-11-12T19:32:20  <sipa> devrandom: feel free
286 2019-11-12T19:32:28  <devrandom> OK
287 2019-11-12T19:32:57  <devrandom> group 3 Q/?: "Just like other existing output types, taproot outputs should never reuse keys" - this is for the standard privacy reason, as in "don't reuse addresses"?
288 2019-11-12T19:32:59  <jnewbery> would there ever be a reason to need more than one annex?
289 2019-11-12T19:33:19  <sipa> jnewbery: possibly
290 2019-11-12T19:33:50  <aj> jnewbery: if you need a per input timelock and are using OP_ZKVERIFY, you'd use two annex entries maybe
291 2019-11-12T19:34:26  <cdecker> Couldn't they be serialized back to back then?
292 2019-11-12T19:34:28  <jnewbery> so should we change the definition to be that any n trailing witness elements starting 0x50 are annexes?
293 2019-11-12T19:34:58  <sipa> jnewbery: yes, that's possible, but concatenating them is more efficient i think
294 2019-11-12T19:35:04  <aj> 0x50 { <len> <tag> <values> } seems a fine encoding to only use a single witness element
295 2019-11-12T19:35:14  <jnewbery> got it
296 2019-11-12T19:35:34  <aj> (makes lightning people twitch since they like tag/length/value though)
297 2019-11-12T19:35:53  <sipa> it's also a tradeoff between taking a complexity hit now, and wondering whether we'll ever even need it
298 2019-11-12T19:36:05  <cdecker> aj: just thought the same :-)
299 2019-11-12T19:36:13  <nickler> devrandom: agree that this is confusing. Made more sense when the section was called Privacy.
300 2019-11-12T19:36:24  <sipa> by saying some annex but not specifying any of its semantics we maximally defer the complexity to when it's needed
301 2019-11-12T19:36:46  <jnewbery> sipa: makes sense. Thanks
302 2019-11-12T19:39:00  <sipa> pyskell: the comment on the tagged hashes use refers to all sha256 anywhere in any protocol related to bitcoin
303 2019-11-12T19:39:05  <sipa> not just inside script
304 2019-11-12T19:39:20  <sipa> and the effect of being wrong about it is very likely nothing
305 2019-11-12T19:40:08  <sipa> in most cases tagged hashing is not needed
306 2019-11-12T19:40:19  <jnewbery> The control block can just be (one leading byte plus) the tapleaf hash in the case where only one script is committed. I thought it was slightly interesting that this is the only case where you can know for sure that no other spending conditions were committed to (with keypath spend you don't know whether there was a tweak and with a taptree spend you don't know the other branches)
307 2019-11-12T19:40:52  <sipa> jnewbery: good point
308 2019-11-12T19:41:07  <devrandom> group 3 Q 3/?: there was some group discussion about the fact that specifying the pubkey in the output saves bytes in the blockchain overall, but it's actually heavier in *vbytes*.  The discussion then got into whether the weight calculation should be different for taproot (I assume so as to encourage use by not penalizing with higher fees).  what do you think?
309 2019-11-12T19:41:35  <pyskell> sipa: Gotcha, thanks for clarifying
310 2019-11-12T19:41:42  *** michaelfolkson has quit IRC
311 2019-11-12T19:41:54  <waxwing> devrandom, i think i remember coming up with 1.5 vbytes heavier for p2tr vs p2wpkh when discussing it with aj last week
312 2019-11-12T19:41:55  <sipa> devrandom: for starters, i don't think this matters, because the output cost is paid by the sender
313 2019-11-12T19:41:59  <waxwing> i mean average of course, not exact
314 2019-11-12T19:42:28  <sipa> and the sender is already willing to pay fot 32-byte witness programs, or he'd not have implemented bip173
315 2019-11-12T19:43:00  <waxwing> that's an argument on segwit v1 vs v0 uptake, but not legacy to v1 uptake right
316 2019-11-12T19:43:06  <sipa> right
317 2019-11-12T19:43:35  <bjarnem> Q: Regarding wording for signature hash:
318 2019-11-12T19:43:35  <bjarnem> Under "Constructing and spending Taproot outputs" -> "Spending using the key path":
319 2019-11-12T19:43:35  <bjarnem> "[...] To do so, a witness stack consists of a single element: a bip-schnorr signature on the signature hash as defined above, [...]" <- Is the "transaction digest" defined above the same as what is called "signature hash" here?
320 2019-11-12T19:43:37  <nickler> waxwing: I came up with 1.25 :) https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7
321 2019-11-12T19:44:25  <waxwing> nickler, lol i'll take it.
322 2019-11-12T19:44:33  <sipa> bjarnem: yep
323 2019-11-12T19:45:10  <devrandom> the difference in vbytes for the sender is (32 - 20) * 4 = 48 if I'm not mistaken.  that said I don't have an opinion about this personally, if anybody from group 3 does they can say something ;)
324 2019-11-12T19:45:26  <moneyball> sipa: thoughts on adjusting the weight calculation to make spending PT2R slightly more favorable? advantage being increased adoption of it + improved privacy/fungibility
325 2019-11-12T19:45:45  <sipa> moneyball: that would be a hard fork. good luck.
326 2019-11-12T19:45:52  <moneyball> oh...
327 2019-11-12T19:46:09  <waxwing> a much less technical point, but our group (6) felt that the Motivation section of BIP-taproot does not actually address the motivation, at least to a reader who doesn't know all historical context. it seems like the motivation is in the "Design" section that immediately follows.
328 2019-11-12T19:47:34  <waxwing> sipa, or maybe swipe a byte or two off the witness program? :)
329 2019-11-12T19:47:51  <bjarnem> sipa: I feel that those terms could be defined as being the same under "Transaction digest", or maybe just use one term. Becuase it also happens in BIP-Taproot that sometimes it refers to the "transaction digest" and other times to the "signature hash". But if they are the same maybe just use one term?
330 2019-11-12T19:48:13  <aj> devrandom: (32-20)*4 gives difference in weight units, vbytes is just (32-20) (and if you were counting witness data, you'd divide that part by 4)
331 2019-11-12T19:48:14  <nickler> bjarnem: agreed
332 2019-11-12T19:48:38  <bjarnem> (edit: I meant also in BIP-TapSCRIPT)
333 2019-11-12T19:48:44  <devrandom> aj: got it
334 2019-11-12T19:49:14  <sipa> waxwing: can you open an issue in my bips repo for that? i think that perhaps needs some more discussion than just a PR
335 2019-11-12T19:49:48  <waxwing> sipa, the motivation? sure yeah that makes sense. i'll copy in the notes i made about it earlier.
336 2019-11-12T19:50:04  <sipa> bjarnem: good point, let's use signature hash everywhere (transaction digest is confusing, as it contains some data that's not actually in the transaction)
337 2019-11-12T19:50:07  <sipa> waxwing: yeah
338 2019-11-12T19:50:35  <aj> sipa: maybe "signature digest" for the stuff you feed into the hash function and "signature hash" for the result?
339 2019-11-12T19:50:55  <aj> sipa: it keeps annoying me there's no term to use for the stuff you feed into the hash
340 2019-11-12T19:51:16  <sipa> aj: "message digest" is a historical name for cryptographic hash function, so i wouldn't use digest to refer to its preimage
341 2019-11-12T19:51:35  <devrandom> group 3 Q 4/?: "The new signature hashing algorithm fixes the verification capabilities of offline signing devices by including amount and scriptPubKey in the digest" - the difference is that segwit commits to input value, but taproot commits to *all* inputs, right?  is the difference mainly for transaction with inputs from different parties?
342 2019-11-12T19:51:41  <aj> sipa: fair
343 2019-11-12T19:52:11  <waxwing> devrandom, yes i was wondering about that, is it related to the kinds of attacks instagibbs came up with wrt coinjoin and similar?
344 2019-11-12T19:52:24  <sipa> devrandom: no, there is an existing issue where you ask a device to sign a 2-input tx twice, and each time you lie about the other input's value
345 2019-11-12T19:52:41  <sipa> the result is that a malicious online wallet can trick an offline wallet in spending more on fees than it intends to
346 2019-11-12T19:54:25  <waxwing> right so not specifically coinjoin but that's one of the main ways it might come up
347 2019-11-12T19:54:32  <sipa> right
348 2019-11-12T19:54:40  <sipa> it's more general than that, but indeed
349 2019-11-12T19:54:53  <bjarnem> I already asked but cannot find an answer, so in case it was overlooked in the discussion here it comes again :)
350 2019-11-12T19:54:54  <bjarnem> Q: What is reasoning behind OP_SUCCESSx instead of only using the available versioning fields to soft-fork new Tapscript logic into the system (e.g. using the leaf version)?
351 2019-11-12T19:55:09  <devrandom> sipa: got it, I assumed that HW wallets signed all inputs at the same time
352 2019-11-12T19:55:11  <sipa> bjarnem: OP_SUCCESSx is the most powerful upgrade mechanism there is
353 2019-11-12T19:55:38  <sipa> bjarnem: if you'd have me pick one of leaf versions, upgradable pubkeys, or op_success, i'd pick the last one
354 2019-11-12T19:56:07  <bjarnem> sipa: Doesn't leaf versioning have the same power, allowing to change the semantics of the script language like segwit versioning??
355 2019-11-12T19:56:29  <sipa> bjarnem: yes, but you need a new leaf version any time you introduce a new opcode for example
356 2019-11-12T19:56:48  <sipa> with OP_SUCCESSx you just pick a number and define it; it can be done in parallel with other new opcodes even
357 2019-11-12T19:57:13  <devrandom> group 3 Q 5/5: should the BIP have a Requires header referring to schnorr, etc.?
358 2019-11-12T19:57:27  <bjarnem> sipa: ah, ok I see that
359 2019-11-12T19:57:46  <sipa> bjarnem: OP_SUCCESSx is the most natural choice for new opcodes, i think; leaf versions are the most natural choice for large redefinitions of the language
360 2019-11-12T19:58:02  <sipa> and leaf versions essentially come at zero cost, because we have a few unused bits in the control block anyway
361 2019-11-12T19:58:12  <sipa> devrandom: yeah
362 2019-11-12T19:58:16  <nickler> devrandom: I think so. there's a PR for that already https://github.com/sipa/bips/pull/135
363 2019-11-12T19:58:17  <bjarnem> sipa: thanks for the clarifiaction of the reasoning!
364 2019-11-12T19:59:16  <sipa> as time is running out here... i feel there have been a lot of good questions here that got a response consisting of a rationale that isn't actually in the BIPs; i'll do an effort to go through the transcript and addressing the ones asked, but feel free to help with that
365 2019-11-12T20:00:04  <aj> "feel free to help" ~= "please do help" :)
366 2019-11-12T20:00:28  <moneyball> shall we wrap?
367 2019-11-12T20:00:29  <sipa> if you got a satisfactory answer, you're probably in the best position to add to the bip exactly what insight would have made the text more clear to you
368 2019-11-12T20:00:44  <devrandom> will PR for the stuff I asked
369 2019-11-12T20:00:50  <sipa> awesome, thanks
370 2019-11-12T20:00:56  <sipa> i need to run, thanks everyone!
371 2019-11-12T20:00:59  <moneyball> #endmeeting
372 2019-11-12T20:01:06  <jonatack> thanks!
373 2019-11-12T20:01:07  *** Moller40_ has joined ##taproot-bip-review
374 2019-11-12T20:01:11  <b10c> Thanks!
375 2019-11-12T20:01:12  <kabaum> Thanks
376 2019-11-12T20:01:15  <bjarnem> Thanks a lot!!
377 2019-11-12T20:01:23  <cdecker> Thanks ^^
378 2019-11-12T20:01:24  <aj> also, quick tip since a few people haven't had much luck getting groups together -- (a) if no one else has taken the initiative to choose a time, or talk about things, that might just be a cue for you to do it; (b) it might be that everyone else in your group really is too busy, so feel free to contact to join a different group
379 2019-11-12T20:01:28  <aj> #endmeeting
380 2019-11-12T20:01:28  <lightningbot> Meeting ended Tue Nov 12 20:01:28 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
381 2019-11-12T20:01:28  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.html
382 2019-11-12T20:01:28  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.txt
383 2019-11-12T20:01:28  <lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.log.html
384 2019-11-12T20:01:43  <fjahr> thanks
385 2019-11-12T20:01:47  <chm-diederichs> thanks
386 2019-11-12T20:01:47  <aj> so i guess that answers my question about whether someone else can end a meeting after it's started too...
387 2019-11-12T20:02:16  <jnewbery> Thanks everyone!
388 2019-11-12T20:04:02  *** Moller40 has quit IRC
389 2019-11-12T20:05:43  <waxwing> yeah thanks
390 2019-11-12T20:06:11  <waxwing> to play devil's avocado, 'signature hash' is unfortunate since it suggests hashing a signature, 'transaction digest' is obscure but descriptive.
391 2019-11-12T20:06:25  <waxwing> ironically the whole point of segwit is to not do (some) 'signature hashing' :)
392 2019-11-12T20:07:17  *** daniel-k7 has joined ##taproot-bip-review
393 2019-11-12T20:10:14  <bjarnem> waxwing: "transaction digest" for me is also more expressive and easier to understand immediately.
394 2019-11-12T20:10:43  <sipa> we'd still need a term for the preimage of that transaction digest
395 2019-11-12T20:10:55  <r251d> For me, the BIPs didn't make it clear whether a single transaction would have one or more "transaction digest". If there would's one digest per input, then "signature digest" seems less confusing.
396 2019-11-12T20:11:42  <sipa> r251d: fair point
397 2019-11-12T20:15:47  <aj> r251d: there's potential a different digest per signature within an input if you have a tapscript that wants multiple signatures (eg if the sigs have different sighashes chosen, or if there are op_codeseparator's between them)
398 2019-11-12T20:16:37  <sipa> different inputs (including different annexes in them), different codeseps, different sighash bytes, ...
399 2019-11-12T20:24:37  <bjarnem> Would the names "transaction-digest" for the _preimage_ and "hashed-transaction-digest" for the hash-value the signature is calculated for be too crazy? :)
400 2019-11-12T20:25:19  <aj> bjarnem: sipa mentioned above the academic crypto community uses "digest" for the hash not the preimage, so using it for the preimage would be confusing
401 2019-11-12T20:25:49  <r251d> "Transaction digest" is probably fine if the BIP clarifies that multiple such digests can be in one tx.
402 2019-11-12T20:28:23  <instagibbs> cdecker, fwiw I think the OP_SUCCESSX parsing part could be more explicit noting it's not the script execution step. The footnote makes it abundantly clear at least with rationale
403 2019-11-12T20:29:56  <bjarnem> Hopefully some good, descriptive term will show up in time in a heureka moment!
404 2019-11-12T20:30:00  <bjarnem> Thanks all!
405 2019-11-12T20:30:04  *** bjarnem has left ##taproot-bip-review
406 2019-11-12T20:38:15  <instagibbs> waxwing, I think I told you about both, the coinjoin one is the lying about whose inputs are whose.
407 2019-11-12T20:38:24  <instagibbs> which is related but not solved
408 2019-11-12T20:46:16  <instagibbs> (by script enhancements)
409 2019-11-12T20:51:25  <waxwing> instagibbs, i see right the coinjoin one can't be solved by this because it's about who owns it, not the amount. duh.
410 2019-11-12T20:51:47  *** KeithMukai has quit IRC
411 2019-11-12T20:55:01  <instagibbs> yep, the input amount can be as simple as fee dumping attacks on hww
412 2019-11-12T20:58:28  *** daniel-k7 has quit IRC
413 2019-11-12T21:04:06  <devrandom> ("signature preimage" and "signature digest"?)
414 2019-11-12T21:20:01  <sipa> seems reasonable to me
415 2019-11-12T21:26:55  <felixweis> different sizes for Q are allowed. what if for shorter Qs presume 0 byte fillers? so people who really want lower output script weight than p2wpkh can use vanitygen to create such.
416 2019-11-12T21:33:02  <felixweis> devrandom: renaming to reduce confusion is very welcome
417 2019-11-12T21:37:11  <sipa> felixweis: that breaks upgradable key types
418 2019-11-12T21:39:50  <sipa> oh, you mean for the witness program? that seems pointless as it's a cost paid by someone else
419 2019-11-12T21:41:02  <sipa> and a pretty big philosophical break from trying to make all outputs look indistinguishable
420 2019-11-12T21:41:43  <felixweis> yes, i wasnt also too serious actually. but it came into mind when reading the QA session and the 1.25 value
421 2019-11-12T21:42:29  *** michaelfolkson has joined ##taproot-bip-review
422 2019-11-12T21:46:19  *** b10c has quit IRC
423 2019-11-12T21:56:54  *** michaelfolkson has quit IRC
424 2019-11-12T22:03:16  *** michaelfolkson has joined ##taproot-bip-review
425 2019-11-12T22:04:40  *** michaelfolkson has quit IRC
426 2019-11-12T22:11:03  *** Chris_Stewart_5 has quit IRC
427 2019-11-12T22:27:13  *** HighOnBtc has joined ##taproot-bip-review
428 2019-11-12T22:33:44  *** sergei-t has left ##taproot-bip-review
429 2019-11-12T23:07:24  *** hebasto has quit IRC
430 2019-11-12T23:08:42  *** hebasto has joined ##taproot-bip-review
431 2019-11-12T23:38:01  *** Chris_Stewart_5 has joined ##taproot-bip-review