1 2019-11-28T00:20:06  *** michaelfolkson has quit IRC
  2 2019-11-28T01:35:01  <sipa> no q&a?
  3 2019-11-28T01:35:06  <sipa> in half an hour?
  4 2019-11-28T01:52:51  <gmaxwell> sipa: you can ask me questions!
  5 2019-11-28T02:00:01  <moneyball> I’ve asked sipa before but I’ll ask again for clarity. Is it possible with taproot to use a trusted third party as an emergency backup key co-signer and retain privacy on your balance and spends as long as you don’t utilize their key? (Like a Casa 3of5 where they have one of the keys)
  6 2019-11-28T02:02:49  *** ZmnSCPxj_ has quit IRC
  7 2019-11-28T02:10:53  <gmaxwell> moneyball: the most straight forward way would be to put their key under a branch rather than at the top level.
  8 2019-11-28T02:11:59  <gmaxwell> moneyball: the normal way to make a schnorr threshold signature require interaction. The interaction doesn't actually break your privacy, but I assume for that application you also don't want the interaction.
  9 2019-11-28T02:12:23  <aj> gmaxwell: i think you'd want to pair it was an "OP_RETURN nonce" script, so that you'd never reveal the script hash even if you wanted to spend via some other script
 10 2019-11-28T02:12:30  <gmaxwell> (or at least the interaction doesn't necessarily break your privacy.)
 11 2019-11-28T02:13:00  <gmaxwell> aj: well normally what you do to hide a key is tweak it, which has no overhead.
 12 2019-11-28T02:13:37  <aj> gmaxwell: though you'd have to keep the merkle path to their script more redundantly than you kept your private keys
 13 2019-11-28T02:13:57  <gmaxwell> aj: well 3 of 5 right, so you put all the setup information with every copy of your keys.
 14 2019-11-28T02:14:11  <gmaxwell> (or a seed which is used to generate your setup info)
 15 2019-11-28T02:15:06  <aj> gmaxwell: yeah. if you tweak their key should be fine to be at the top level privacy-wise
 16 2019-11-28T02:15:43  <gmaxwell> aj: tweak works toplevel or in a branch, really there should never be a reason for a nonce in a branch that contains a pubkey.
 17 2019-11-28T02:16:22  <gmaxwell> instead you just compute some H(pubkey||chaincode||index)G+P and have that in the branch.
 18 2019-11-28T02:17:45  <gmaxwell> The top level has an additional storage complication though, since you have to do an interactive protocol and store the result.  E.g. casa couldn't just publish a pubkey which you can add as a backup without ever talking to them.
 19 2019-11-28T02:18:48  <aj> top level as in key path, do you mean?
 20 2019-11-28T02:19:21  <gmaxwell> FWIW, that kind of backup service could also be done so that it's private even when used.  Where you make a version of pubkey tweaked a commitment to your identity,  ... then if you want them to backup sign for you, you could prove your identity and ask them to blind sign, so they never see the txn they're signing for.
 21 2019-11-28T02:19:25  <gmaxwell> aj: yes.
 22 2019-11-28T02:19:44  <aj> ah, i was meaning top level as in when there was only one tapscript
 23 2019-11-28T02:20:29  <moneyball> gmaxwell: that’s interesting I didn’t realize that
 24 2019-11-28T02:21:19  *** rottensox_ has joined ##taproot-bip-review
 25 2019-11-28T02:22:29  <gmaxwell> Another way of doing the "never see the txn",  is that you ask them to generate a keypair for you, and give you the pubkey but you only use it in tweaked form so they can't see it being used.  Then later, if you need it in an emergency, you identify to them and then they give you the private key.
 26 2019-11-28T02:22:44  <gmaxwell> And that even works with ECDSA.
 27 2019-11-28T02:23:27  <gmaxwell> There was some 'blockchain oracle' service called reality keys that published pubkeys for events, and depending on the outcome published one or the other private keys... which worked with this sort of use.
 28 2019-11-28T02:23:52  <gmaxwell> The 'give away the private key' usage isn't compatible with public derrivation sadly.
 29 2019-11-28T02:24:14  *** rottensox has quit IRC
 30 2019-11-28T02:25:49  *** rottensox__ has joined ##taproot-bip-review
 31 2019-11-28T02:28:21  *** rottensox_ has quit IRC
 32 2019-11-28T02:30:23  *** ZmnSCPxj has joined ##taproot-bip-review
 33 2019-11-28T02:35:12  <gmaxwell> The right intution though is that _any_ key can be made private prior to its use by adding tweake*G to it, -- private to anyone that doesn't know that tweak value.  This is true for ECDSA just as well, e.g. BIP32 public derrivation is essentially that.
 34 2019-11-28T02:35:49  <gmaxwell> For schnorr you just also gain the ability to do thresholds, but it works the same there. Come up with some threshold key P,  and tweak it.
 35 2019-11-28T02:38:20  <gmaxwell> The 'interactive setup' for a threshold key is that each person generates an secret. Then each person N of M shares their secret using a verifyable secret sharing scheme. Everyone checks that the shares are all consistent.  Everyone adds up all the shares they recieved.   So the final result is each party learns an N of M share of the sum of everyone's secrets. Once you've done that, you can
 36 2019-11-28T02:38:20  <gmaxwell> go ahead and just tweak the result to keep it private from participants not knowing the tweak.
 37 2019-11-28T02:38:33  *** rottensox__ is now known as rottensox
 38 2019-11-28T02:39:19  <ZmnSCPxj> "_any_ key can be made private": just to be clear, this means "any published pubkey can be used to create an unpublished pubkey that the original published pubkey signer(s) can sign for"
 39 2019-11-28T02:40:02  <gmaxwell> And since the tweak is mathmathcically equivient to AND-ing knowledge of the secret in the policy. (so your N of M policy because ((N of M) AND TWEAK)) it should just drop right into the signing process-- by either just adding the tweak to one of the signers' keys or by adding a 'fake participant' that signs with the tweak key.
 40 2019-11-28T02:40:47  <gmaxwell> And the same also works w/ blind signing.
 41 2019-11-28T02:41:04  <ZmnSCPxj> Would adding just `e * tweak * G` to the summed final `s` be enough?
 42 2019-11-28T02:41:39  <gmaxwell> -tweak, I believe if you want to be pedantic.
 43 2019-11-28T02:41:44  <aj> ZmnSCPxj: you want to add "x" so they can't mention on the nonce they signed too
 44 2019-11-28T02:41:46  <ZmnSCPxj> ok
 45 2019-11-28T02:41:58  <aj> if you're doing blind sigs at least
 46 2019-11-28T02:42:02  <gmaxwell> If you're _blind_ signing you have to hide the nonce.
 47 2019-11-28T02:42:24  <gmaxwell> which means the signer can't see the input to e... and there are some additional security considerations.
 48 2019-11-28T02:43:44  <gmaxwell> [and anyone reading this log in the future should be aware that virtually all descriptions of blind signatures out there are insecure and ignore wagner's algorithim, but it's possible to securely do... which should be sufficient for discussing taproot functionality]
 49 2019-11-28T02:44:09  <gmaxwell> sipa: so you're not gonna ask me any questions? :(
 50 2019-11-28T02:44:24  <ZmnSCPxj> Hmmm why `-tweak`? bip-schnorr uses `k + ed`
 51 2019-11-28T02:45:15  <ZmnSCPxj> Or possibly based on whether it is square or not
 52 2019-11-28T02:46:25  <gmaxwell> ZmnSCPxj: ah right you are. (sorry thought without thinking much was "you added it to the key so you should subtract it in the signature" but here you want to be signing for the tweaked value, not having a tweaked signer sign for the original value :P)
 53 2019-11-28T02:47:08  <ZmnSCPxj> okay
 54 2019-11-28T02:47:28  <gmaxwell> in any case, I expect that a complete schnorr multisigning api will end up with some 'tweak input' which must be input as a scalar, and bypasses delinearization.  ... which you will need to sign with taprooted keys, and stuff like this.
 55 2019-11-28T02:47:40  <aj> gmaxwell: sipa just tricked you into asking him a question, i think that means he won
 56 2019-11-28T02:47:41  <gmaxwell> (I dunno what nickler's -zkp interface currently does)
 57 2019-11-28T02:48:16  <ZmnSCPxj> aj: Is that how high-level cryptographers play?
 58 2019-11-28T02:49:05  <gmaxwell> aj: it's a zero knoweldge protocol, we can't even tell if he's here or not.
 59 2019-11-28T02:50:26  <ZmnSCPxj> I believe I have seen elsewhere that blind Schnorr signing can be fixed somehow by requiring multiple blind signing attempts and then rejecting all except one that you randomly select, is that correct?
 60 2019-11-28T02:51:50  <gmaxwell> ZmnSCPxj: We don't have a security proof for that, but I believe that is secure.
 61 2019-11-28T02:52:54  <gmaxwell> Alternatively, you can only have exactly one signing session going at any one point in time, and begin a second only when the first finishes or times out.
 62 2019-11-28T04:29:21  *** shesek has quit IRC
 63 2019-11-28T04:29:46  *** shesek has joined ##taproot-bip-review
 64 2019-11-28T04:29:46  *** shesek has joined ##taproot-bip-review
 65 2019-11-28T05:08:49  <gmaxwell> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017495.html  < wouldn't this require a lot more hashing?
 66 2019-11-28T05:10:30  <sipa> gmaxwell: you mean at signing time
 67 2019-11-28T05:10:33  <sipa> ?
 68 2019-11-28T05:11:54  <gmaxwell> at verification time
 69 2019-11-28T05:12:28  <sipa> i thought about responding that this woukd break scenarios where the signer acrually doesn't know the checksig execution time (bexause it may depend on which other signers are availavle)
 70 2019-11-28T05:12:47  <sipa> but i don't actually know any such scenario
 71 2019-11-28T05:12:53  <sipa> gmaxwell: no, 4 bytes
 72 2019-11-28T05:13:00  <sipa> per checksig
 73 2019-11-28T05:14:34  <gmaxwell> sipa: but it requires invoking the sha256 compression function for each checksig operation when otherwise they'd share them, no?
 74 2019-11-28T05:14:54  <gmaxwell> sipa: if there is a long checksig add sequence, you'll know which checksig you're signing for, but not which other ones will be used.
 75 2019-11-28T05:14:56  <sipa> gmaxwell: oh, yes, but only at the end
 76 2019-11-28T05:15:18  <sipa> so you could use midstate caching if you really wamted to
 77 2019-11-28T05:15:38  <gmaxwell> sure, but even if you do that it'll still be an extra compression function run per checksig.
 78 2019-11-28T05:16:29  <sipa> that seems a very marginal issue
 79 2019-11-28T05:16:42  <sipa> i'm more concerned about complicating implementation of  orrect signers
 80 2019-11-28T05:16:45  <sipa> *correct
 81 2019-11-28T05:18:36  <gmaxwell> The benefit of the change is unclear to me-- at least the example roconnor gives doesn't work AFAIK-- you already sign the script you're signing for, so you won't get substituted for a whole different script.
 82 2019-11-28T05:19:17  <gmaxwell> I mean, it essentially reitroduces a quadratic validation cost (though with a pretty small constant)
 83 2019-11-28T05:19:29  <sipa> no, it doesn't
 84 2019-11-28T05:19:40  <sipa> the cost per checksig is constant, with or without this change
 85 2019-11-28T05:20:02  <gmaxwell> okay, true _if_ you midstate cache.
 86 2019-11-28T05:20:19  <sipa> no, even if you do 't
 87 2019-11-28T05:20:47  <sipa> because all variable-length data fed to the sighash is precomputed per tx or per input
 88 2019-11-28T05:21:38  <sipa> midstate caching lets you reduce it from 200 ish bytes max to a few bytes (+ hashing of padding)
 89 2019-11-28T05:24:27  <sipa> if you know of an example where a signer in general wouldn't be able to predict the checksig position for a given signature he's producing, i'd very much like to hear it
 90 2019-11-28T05:24:57  <sipa> i'm also not convinced this change improves very much
 91 2019-11-28T05:25:02  <sipa> in practice
 92 2019-11-28T05:26:14  <gmaxwell> Some back of the envelope math suggests to me that this might asympotically slow validation by about 2%
 93 2019-11-28T05:26:49  <sipa> assuming you i.
 94 2019-11-28T05:27:06  <sipa> assuming you implement the caching of sighashes to begin with, you mean?
 95 2019-11-28T05:28:27  <gmaxwell> yes, and assuming batch validation is in use with ~infinite batch sizes... and assuming the transaction is all lots of checksigs in a single script. (ignoring the limits on scriptsize)
 96 2019-11-28T05:29:24  <gmaxwell> basically 2*sqrt+affine-add+2-fieldmul+sha2compression vs that plus one more sha2compression. (no sha-ni)
 97 2019-11-28T05:29:27  <sipa> it's only an average case performanxe reduction though, not a worst case one
 98 2019-11-28T05:29:51  <sipa> (as in the worst case you'd use codesep for every chechsig already?
 99 2019-11-28T05:30:17  <gmaxwell> ah. codesep... well thats why bluematt wants to get rid of codesep.
100 2019-11-28T05:30:18  <gmaxwell> :)
101 2019-11-28T05:30:36  <sipa> that's not really comparable
102 2019-11-28T05:30:59  <sipa> the effect in legacy sighashes is much more significant
103 2019-11-28T05:33:08  <gmaxwell> sipa: so my understanding of his concern is that you have a script leaf  where you have something like "if hash160 equalverify pubkey1 checksigverify else pubkey2 checksigverify endif",  and you're tricked into signing for the second clause when you think you're signing for the first.
104 2019-11-28T05:33:42  <gmaxwell> as avoiding this rebinding would require doing stuff like making sure your pubkey only happens in the expected place and not someplace else.
105 2019-11-28T05:36:47  <sipa> gmaxwell: it's primarily an issue if you reuse the same pubkey in multiple places in a script
106 2019-11-28T05:37:56  <sipa> but (a) it's not even a full protection in that case (multiple code paths resulting in the same pubkey does not imply the checksig position will be different; ideally you'd sign all the if/then/else and other conditionals in the whole script
107 2019-11-28T05:38:16  <gmaxwell> sipa: but the 'reuse' might be done by another user.
108 2019-11-28T05:38:33  <gmaxwell> If you sign all the conditions that will absolutely break non-interactive checkmultisig like usage.
109 2019-11-28T05:39:05  <sipa> yep.
110 2019-11-28T05:39:09  <sipa> i agree with that
111 2019-11-28T05:39:43  <sipa> i feel like this exact suggestions doesn't break much in practice,but also does 't protect aginst much in practice
112 2019-11-28T05:39:54  <ZmnSCPxj> Would banning `OP_IF` and forcing every branch to use MAST work?
113 2019-11-28T05:40:04  <gmaxwell> I think if you sign _which_ checksig you were executing (as in like it's byte position in the witness program) then thats sufficient for his concern.
114 2019-11-28T05:40:15  <sipa> ZmnSCPxj: that woukd absolutely kill a whole bunch of interesting use cases
115 2019-11-28T05:40:17  <gmaxwell> ZmnSCPxj: that would be tremendiously destructive.
116 2019-11-28T05:40:24  <ZmnSCPxj> ok
117 2019-11-28T05:41:31  <sipa> gmaxwell: that's exactly what he's suggesting
118 2019-11-28T05:41:47  <sipa> (except it's opcode number, not byte position)
119 2019-11-28T05:42:47  <gmaxwell> ZmnSCPxj: imagine your policy is like a 25 of 100... you can't build a MAST tree of that-- it would be about 2^80 hashing operations to do so.  Yet it's a fairly straight forward script otherwise, not even terribly expensive fees wise.
120 2019-11-28T05:44:10  <gmaxwell> sipa: opcode number is maybe a little softfork hostile though, since it means the counting needs to be consistent in implementations with different rules.
121 2019-11-28T05:44:26  <sipa> gmaxwell: i don't think that is hard
122 2019-11-28T05:44:48  <gmaxwell> K.
123 2019-11-28T05:44:55  <gmaxwell> (no strong opinion)
124 2019-11-28T05:47:02  <gmaxwell> I guess there is no performance overhead (well depending on how much data is going into hashes) in the common case that there is only a single checksig in any case.
125 2019-11-28T05:47:23  <gmaxwell> and no increase in the worst case, as you note.
126 2019-11-28T05:47:25  <ZmnSCPxj> For 25 of 100, is not `OP_CHECKSIGADD` enough? There is still no need for `OP_IF`?
127 2019-11-28T05:48:13  <gmaxwell> sipa: so, if the pubkey going into the checksig is decided by an earlier part of the script, you may not know your position.
128 2019-11-28T05:48:55  <sipa> gmaxwell: yep, i see how that is the case in theory
129 2019-11-28T05:48:56  <gmaxwell> ZmnSCPxj: if you want to be forced to have an extra 75 zero pushes for no good reason. :P
130 2019-11-28T05:49:13  <gmaxwell> ZmnSCPxj: though replace my example with a bunch of hash preimages and your dodge goes away.
131 2019-11-28T05:49:24  <sipa> gmaxwell: i wanted to bring that uo, but i can't actually come up with a useful script that needs this
132 2019-11-28T05:49:41  <sipa> even the crazy 3-of-10000 wouldn't be affected
133 2019-11-28T05:50:03  <gmaxwell> sipa: well if OP_CAT is reenabled then e.g. pubkey checked against a hashtree in the script is potentially such a case.
134 2019-11-28T05:50:19  <sipa> gmaxwell: mmmmaybe
135 2019-11-28T05:50:39  <gmaxwell> it could be controlled by a sighash flag...
136 2019-11-28T05:50:46  <gmaxwell> :-/
137 2019-11-28T05:52:47  <gmaxwell> so for example, a OP_CAT key tree that emerges a couple keys from the tree, and checks that they're distinct, then checksigs with them, -- like a way of doing the 4 of 10000 that doesn't include 10,000 pubkeys in the witness program.
138 2019-11-28T05:53:12  <gmaxwell> you couldn't non-interactively sign for that, if the checksig positions are tagged (except via signing for each of the 4 possibilities)
139 2019-11-28T05:57:50  <gmaxwell> (or change that to 4 of 65535 and then you even get a script that there is no other way to construct, yet is reasonably efficient to use, non-interactively signable, etc...)
140 2019-11-28T05:58:47  <gmaxwell> If it somehow signed it's location in terms of which _branch_ rather than which checksig,  it wouldn't break that case anymore.
141 2019-11-28T05:59:24  <gmaxwell> like the opcode location of the nearest enclosing if.
142 2019-11-28T05:59:57  <gmaxwell> (so every 'if' acts like a codeseperator for this purpose)
143 2019-11-28T06:00:30  <ZmnSCPxj> gmaxwell: "though replace my example with a bunch of hash preimages and your dodge goes away." `OP_SWAP OP_HASH160 <hash> OP_EQUAL OP_ADD`, which is equivalent to `OP_CHECKSIGADD` except for hashes?
144 2019-11-28T06:01:37  <ZmnSCPxj> Or `OP_ADD` is not enabled yet?
145 2019-11-28T06:03:58  <gmaxwell> that works, but consider-- you've removed IFs and now so any conditional operation people have to just accomplish using arithmetic thresholds..okay, but then roconnor's concern about your signing for the wrong checksig still applies.  The complaint I had about your original suggestion is that requiring all control flow to be precomputed in the hashtree is pratically limiting...
146 2019-11-28T06:05:17  <gmaxwell> So: you can't replace "effectively conditional" logic in scripts with the tree because of exponential blowup in converting to disjunctive form.  And any workaround to preserve conditional behavior (e.g. by doing it with arithmetic) still has the 'you might sign the wrong place' issue.
147 2019-11-28T06:06:42  <gmaxwell> sipa: an alternative that maybe people would hate is that checksig could reject any script that reuses a pubkey.
148 2019-11-28T06:06:57  <gmaxwell> so leaving it on validation to catch those cases, instead of the signer.
149 2019-11-28T06:06:57  <ZmnSCPxj> okay
150 2019-11-28T06:12:38  *** achow101 has quit IRC
151 2019-11-28T06:13:44  *** mryandao_ has quit IRC
152 2019-11-28T06:14:02  *** achow101 has joined ##taproot-bip-review
153 2019-11-28T06:14:03  *** mryandao has joined ##taproot-bip-review
154 2019-11-28T07:38:11  *** belcher has joined ##taproot-bip-review
155 2019-11-28T07:39:08  *** ZmnSCPxj has quit IRC
156 2019-11-28T09:42:35  *** b10c has joined ##taproot-bip-review
157 2019-11-28T10:01:00  *** jonatack_ has joined ##taproot-bip-review
158 2019-11-28T10:05:02  *** jonatack has quit IRC
159 2019-11-28T10:08:00  *** shesek has quit IRC
160 2019-11-28T10:11:16  *** shesek has joined ##taproot-bip-review
161 2019-11-28T10:35:17  *** rottensox_ has joined ##taproot-bip-review
162 2019-11-28T10:36:51  *** rottensox__ has joined ##taproot-bip-review
163 2019-11-28T10:37:58  *** rottensox has quit IRC
164 2019-11-28T10:39:37  *** rottensox_ has quit IRC
165 2019-11-28T10:41:00  *** rottensox__ is now known as rottensox
166 2019-11-28T12:29:09  *** shesek has quit IRC
167 2019-11-28T12:47:36  <nickler> ZmnSCPxj: it seems to turn out that fixing blind schnorr signing by randomly selecting challenges (which doesn't imply additional rounds just 128 times size blowup in 2 rounds) is plausible. https://eprint.iacr.org/2019/877 shows that in ROM+Algebraic group model blind schnorr signing is secure if one more discrete log and "modified ROS" is hard.
168 2019-11-28T12:47:41  <nickler> modified ROS is the probabilistic version of the ROS problem that Wagner's algorithm solves in normal blind schnorr sigs. It's not clear if it's hard, but it certainly seems so.
169 2019-11-28T13:11:09  *** b10c has quit IRC
170 2019-11-28T13:11:52  *** b10c has joined ##taproot-bip-review
171 2019-11-28T13:15:23  *** evoskuil[m] has quit IRC
172 2019-11-28T13:15:34  *** b10c has quit IRC
173 2019-11-28T14:40:24  *** evoskuil[m] has joined ##taproot-bip-review
174 2019-11-28T15:47:47  *** davterra has quit IRC
175 2019-11-28T15:50:32  *** davterra has joined ##taproot-bip-review
176 2019-11-28T15:58:06  *** davterra has quit IRC
177 2019-11-28T16:34:49  *** b10c has joined ##taproot-bip-review
178 2019-11-28T16:38:43  *** b10c has quit IRC
179 2019-11-28T16:38:54  *** b10c has joined ##taproot-bip-review
180 2019-11-28T16:42:19  *** b10c has quit IRC
181 2019-11-28T16:42:32  *** b10c has joined ##taproot-bip-review
182 2019-11-28T17:11:37  *** dr-orlovsky has quit IRC
183 2019-11-28T17:16:33  *** devrando1 has joined ##taproot-bip-review
184 2019-11-28T17:50:29  *** devrando1 has quit IRC
185 2019-11-28T18:29:02  *** b10c has quit IRC
186 2019-11-28T18:29:15  *** b10c has joined ##taproot-bip-review
187 2019-11-28T18:45:16  *** andrewtoth_ has quit IRC
188 2019-11-28T18:56:53  *** andrewtoth_ has joined ##taproot-bip-review
189 2019-11-28T19:10:46  *** andrewtoth_ has quit IRC
190 2019-11-28T19:11:28  *** andrewtoth_ has joined ##taproot-bip-review
191 2019-11-28T20:12:30  *** arik_ has joined ##taproot-bip-review
192 2019-11-28T20:31:14  *** arik_ has quit IRC
193 2019-11-28T20:49:38  *** arik_ has joined ##taproot-bip-review
194 2019-11-28T20:57:16  *** arik_ has quit IRC
195 2019-11-28T21:01:35  *** b10c has quit IRC
196 2019-11-28T21:10:25  *** jonatack__ has joined ##taproot-bip-review
197 2019-11-28T21:11:58  *** jonatack_ has quit IRC
198 2019-11-28T21:24:36  *** jonatack__ has quit IRC
199 2019-11-28T21:24:51  *** jonatack has joined ##taproot-bip-review
200 2019-11-28T21:26:55  *** devrando1 has joined ##taproot-bip-review
201 2019-11-28T21:27:31  *** jonatack has quit IRC
202 2019-11-28T21:27:51  *** jonatack has joined ##taproot-bip-review
203 2019-11-28T21:55:34  *** ghost43 has joined ##taproot-bip-review
204 2019-11-28T22:01:16  *** jonatack_ has joined ##taproot-bip-review
205 2019-11-28T22:04:34  *** jonatack has quit IRC
206 2019-11-28T22:28:28  *** dr-orlovsky has joined ##taproot-bip-review
207 2019-11-28T22:35:20  *** rottensox_ has joined ##taproot-bip-review
208 2019-11-28T22:37:59  *** rottensox has quit IRC
209 2019-11-28T23:16:49  *** andrewtoth_ has quit IRC
210 2019-11-28T23:17:04  *** andrewtoth_ has joined ##taproot-bip-review
211 2019-11-28T23:30:36  *** arik_ has joined ##taproot-bip-review
212 2019-11-28T23:36:17  *** arik_ has quit IRC
213 2019-11-28T23:55:22  *** arik_ has joined ##taproot-bip-review