--- Day changed Tue Nov 26 2019
00:01 -!- jonatack_ [~jon@37.164.112.70] has joined ##taproot-bip-review     
00:04 -!- jonatack [~jon@37.173.132.239] has quit [Ping timeout: 276 seconds]     
00:08 -!- hebasto [~hebasto@95.164.65.194] has quit [Ping timeout: 252 seconds]     
00:08 -!- hebasto [~hebasto@95.164.65.194] has joined ##taproot-bip-review     
00:14 -!- ZmnSCPxj___ [9258463b@146.88.70.59] has joined ##taproot-bip-review     
00:15 < ZmnSCPxj___> aj: True, though note this still requires 1.5 round trips to forward, whereas fast forwards requires 0.5 round trips and the signing for the new commitment transactions is no longer on the hot path.
00:16 < ZmnSCPxj___> However fast forward requires symmetrical  CSVs, I believe there was an argument recently against syemmtrical CSVs.
00:29 < aj> ZmnSCPxj___: hmm, that doesn't sound right, but i've definitely lost track of what non-eltoo taproot ln scripts might look like
00:40 < ZmnSCPxj___> there has not been *any* discussion of taproot usage in Lightning yet. Perhaps I should spam another article on lightning-dev, I have not been spamming it enough recently....
00:41 < ZmnSCPxj___> I mean in relation to Poon-Dryja, not Decker-Russell-Osuntokun
00:41 < ZmnSCPxj___> Taproot use for Decker-Russell-Osuntokun has had some discussion, but potentially not enough.
00:44 < aj> ZmnSCPxj___: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001038.html
00:46 < aj> https://github.com/ElementsProject/scriptless-scripts/blob/master/md/multi-hop-locks.md has some links too, but that was the only poon-dryja one i think
00:47 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Quit: Konversation terminated!]     
00:48 -!- b10c [~Thunderbi@mue-88-130-54-176.dsl.tropolys.de] has joined ##taproot-bip-review     
00:50 < ZmnSCPxj___> Your first link seems to point only to Schnorr, not *taproot*, so...................
00:50 < ZmnSCPxj___> :)     
00:52 < ZmnSCPxj___> as does the second; it is about scriptless script, not tapscript, I think.
00:53 < ZmnSCPxj___> So far there has been no discussion on the use of taproot in Lightning, from what I can tell; I believe the thought was that everything could be done with pre-signed txes and scriptless script.
00:53 < ZmnSCPxj___> Even revocation I believe could be done with scriptless script.
00:54 < ZmnSCPxj___> No, not even scriptless. Just give your secret as the revocation key, since you do not exchange the revocation key for anything other than the continuation of the protocol.
00:57 < ZmnSCPxj___> i.e. to-self output would be a 2-of-2 MuSig between you and counterparty with temporary  keys, you get a presigned transaction that spends that output and gives it to you, but with a `nSequence` encumbrance; then to revoke that you give the secret to that key, which lets the counterparty spend it completely without you as it now knows both secrets.
01:00 < gmaxwell> I've wondered what you could do with a tree of distinct CSVs and you incrementally hand out private keys at different CSV levels, closer and closer to current.
01:07 < aj> ZmnSCPxj___: yeah, if you don't care about all the round trips for musig, i think everything works scriptlessly, which means you just need schnorr not taproot
01:08 < aj> ZmnSCPxj___: if you want to minimise round trips, i think an alternate script path might be worth the extra sigs, but not sure
01:12 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 240 seconds]     
01:15 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 250 seconds]     
01:18 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-bip-review     
01:39 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-bip-review     
01:49 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 268 seconds]     
01:54 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-bip-review     
02:01 -!- ZmnSCPxj___ [9258463b@146.88.70.59] has quit [Ping timeout: 260 seconds]     
02:23 -!- jonatack_ [~jon@37.164.112.70] has quit [Quit: jonatack_]     
02:23 -!- jonatack [~jon@37.164.112.70] has joined ##taproot-bip-review     
02:41 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]     
02:54 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-bip-review     
03:17 < ZmnSCPxj_> gmaxwell: replicates the decrementing-`nSequence` mechanism in Decker Wattenhofer I think
03:18 < ZmnSCPxj_> aj: I think that "alternate script path" technique is something worth discussing on lightning-dev, and is what I was referring to about there not being any discussion about this yet.
03:19 < ZmnSCPxj_> gmaxwell: could be interesting with `OP_SECURETHEBAG` / `OP_CHECKOUTPUTHASHVERIFY`?
03:33 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
04:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
04:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
05:22 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:1119:24d8:4702:d2e2] has joined ##taproot-bip-review     
05:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
05:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
05:48 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has quit [Ping timeout: 250 seconds]     
05:51 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has joined ##taproot-bip-review     
06:14 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:1119:24d8:4702:d2e2] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
07:09 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has joined ##taproot-bip-review     
07:10 -!- pyskell [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review     
07:15 -!- pyskl [~pyskell@194.36.111.51] has joined ##taproot-bip-review     
07:19 -!- pyskell [~pyskell@unaffiliated/pyskell] has quit [Ping timeout: 246 seconds]     
07:32 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]     
07:32 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review     
08:17 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review     
09:09 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review     
09:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
10:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
10:36 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review     
10:38 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
10:42 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
10:44 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review     
10:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]     
10:48 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review     
10:48 -!- shesek [~shesek@185.3.145.80] has quit [Changing host]     
10:48 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review     
11:01 -!- pyskl is now known as pyskell     
11:01 < aj> #startmeeting
11:01 < lightningbot> Meeting started Tue Nov 26 19:01:16 2019 UTC.  The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:01 < pyskell> hi     
11:01 < nickler> hi     
11:01 < kabaum> hi     
11:01 -!- pyskell [~pyskell@194.36.111.51] has quit [Changing host]     
11:01 -!- pyskell [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review     
11:01 < aj> hi     
11:01 < fanquake> hi     
11:01 < sipa> hi     
11:01 < schmidty> hi     
11:03 < kabaum> Good to see you all again.
11:03 < kabaum> Q1/2 group 5: "Transaction digest": scriptPubKey is listed as 35 bytes. Shouldn't that be 34 bytes? OP_1 OP_20 <32 byte witness program>? Is the extra byte a leading varint as in the output? If so, why don't we remove it since it's always 35, well 34, bytes?
11:04 < sipa> kabaum: partially the result of the fact that this existed before P2SH support was removed
11:04 < ariard_> hi     
11:04 < sipa> because back then, scriptPubKey for a P2SH-taproot spend would actually contain the P2SH scriptPubKey
11:04 < sipa> (rather than its redeemscript)
11:06 < sipa> The rationale here is that by default really every signature should commit to vout hash/id, and exact scriptPubKey and amount, as it guarantees offline signing devices can verify the entire path between the claimed UTXO being spent and whatever it commits to
11:06 < jonatack> hi     
11:06 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review     
11:07 < sipa> And the justification is a very minor issue right now where a software wallet could claim to a HW device that it is spending a P2SH-P2WSH output for example, but the real output is a (native) P2WSH one... making the HW device perhaps misrepresent the necessary fees
11:07 < sipa> this specific example could have been fixed by just exactly committing to P2SH or not
11:07 < sipa> but it is not the only example of such mutations
11:08 < sipa> and they're all fixed by just committing to the scriptPubKey
11:08 < sipa> so yes, we know it's always 34 bytes, and could thus drop the compactsize length that precedes it
11:09 < sipa> but as a general principle i think it's better to just make it generic, using an approach that will keep working for other kinds of scriptPubKeys as well
11:09 < sipa> </monologue>
11:10 < kabaum> So maybe it's better to not say "Its size is always 35 bytes" then?
11:11 < sipa> well it is in the specific use in bip-taproot
11:11 < ariard_> how about future extensions of hash_type ? is epoch the versioning number and if so where would you pass the epoch in future extensions, annex?
11:11 < sipa> ariard_: i don't understand
11:11 < kabaum> sipa: sure
11:12 < sipa> oh, i see
11:12 < ariard_> sipa: let's say we want to have new hash_types, how would we introduce them?
11:12 < sipa> ariard_: anyway you like
11:12 < sipa> (if you find consensus)
11:12 < ariard_> sure but the epoch would be the most fine-grained one ?
11:13 < ariard_> compare to the leaf version
11:13 < fjahr> hi     
11:13 < devrando1> hi     
11:13 < sipa> the epoch is not encoded anywhere, it's not an extension mechanism
11:14 < sipa> it's just so that if something needs to introduce a completely new sighash construction, they don't need a new tag for the tagged hash
11:14 < sipa> they can instead just set the epoch to another value, and then do whatever they want
11:14 < sipa> without the risk of ever colliding with a bip-taproot sighash
11:14 < ariard_> hmmm but at least in demo code epoch is hardcoded to zero?
11:15 < sipa> it is not just hardcoded in the demo code to be zero
11:15 < sipa> bip-taproot defines it to be zero
11:15 < nickler> ariard_: the sighash_anyprevout hash type is proposed to be introduced with a new pubkey type
11:15 < sipa> we could just not give it a name
11:15 < sipa> it's just zero
11:16 < ariard_> in SignatureHashSchnorr, epoch = 0
11:16 < sipa> yes     
11:16 < sipa> and bip-taproot says:
11:16 < sipa> epoch (1): always 0
11:16 < ariard_> nickler: using key_version?
11:17 < nickler> yeah
11:17 < sipa> nickler: ariard_ is asking about epoch, not key version
11:17 < ariard_> sipa: yes but I thought you could use epoch as a upgrade mechanism like key version, but apparently that's not the case
11:18 < devrando1> the epoch is not serialized
11:18 -!- midnightmagic is now known as midnight     
11:18 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
11:18 < devrando1> so you can't use it to communicate anything
11:19 < devrando1> it's only part of the data bytes that are hashed, but it's a non-stored constant
11:20 < sipa> i explained it more to ariard_ irl
11:20 < sipa> but i think the epoch can use better justification in the text
11:21 < sipa> really, its goal is to enable reusing the tag "TapSigHash" even in potential hypothetical future sighashes that completely change the data hashed
11:21 < sipa> without risking collisions
11:22 < sipa> so really, this sighash scheme just sets the first byte to 0, so that there is a simple guaranteed way for future sighashes that intend to be different: they can set the first byte to not-0
11:22 < sipa> but as far as bip-taproot is concerned, it's not an extension mechanism; it's just a 0
11:24 < kabaum> sipa: Now I get epoch. Thanks.
11:24 < kabaum> Q2/2: "Transaction digest": The summary at the end: Isn't another difference that in case ANYONECANPAY is set, we don't commit to 32 zero bytes in place of hashPrevous as we did in BIP143, but to nothing regarding prevouts. Or is that too insignificaant to make the list?
11:25 < sipa> kabaum: you cannot commit to 32 zero bytes
11:25 < sipa> there is no information in them
11:25 < sipa> it's an implementation detail that the exact data hashed changed
11:26 < sipa> but in terms of semantics, hashing 32 zero bytes never did anything
11:26 < kabaum> I see.
11:30 < gmaxwell> The important thing is that there isn't an 'aliasing' problem, where a commitment to two different things might be confused.
11:31 < gmaxwell> But you don't need zero stuffing to prevent that, hashing that flags that are in use is sufficient-- actually not just sufficient, better than stuffing without flags.
11:31 < ariard_> Rationale 16: "Despite that, collisions are made impossible by committing to the length of the data before the variable length data", the commitment here is hash_type and spend_type?
11:32 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review     
11:32 < ariard_> but they don't tell you the lenght of the variable length data parts, input outpoints, input amounts, ...?
11:32 < sipa> ariard_: hmm, we may need to revise that
11:32 < sipa> because scriptPubKey is no longer variable length
11:33 < sipa> and all other variable length things have indirect commitments to their lengths using intermediate hashes
11:33 < sipa> (e.g. the annex has its length committed to by being prehashed)
11:34 < ariard_> okay is collision of final hash by tweaking indirect commitments an issue?
11:35 < sipa> we assume we have a collision resistant hash function
11:35 < sipa> so no
11:37 < sipa> ariard_: collisions through indirect hashes are no more a problem that collisions in the directly hashed data is a problem
11:40 < devrando1> none of the hashing in bip-taproot (or existing Bitcoin code) is vulnerable to extension attacks because the hashes are signed, right?
11:40 < devrando1> (vs MACs)
11:40 < ariard_> sipa: yes I see, the problem is back to finding a collision in subhashes like you said
11:40 < sipa> devrando1: length extension attacks apply to MACs
11:40 < sipa> devrando1: we do not use any of our hashes as MACs
11:41 < sipa> (specifically, a MAC implies there is a secret; all our data hashed is public)
11:41 < devrando1> got it
11:44 < sipa> there is a related problem to length extension attacks (and generally apllicable to the same kinds of constructions), namely that IF someone manages to find a collision in a hash function based on Merkle-Damgard, then that can cheaply be extended to be arbitrarily many collisions by suffixing the same data after it
11:44 < sipa> that's not called a length extension attack though
11:44 < sipa> and SHA256 is indeed susceptible to thay
11:45 < sipa> but bitcoin already relies on SHA256 being collision resistant entirely
11:45 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review     
11:47 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds]     
11:47 < ariard_> could you use new public key types to have the public key enforcing hash_types on the signatures, like the "spending transaction must commit to nLockTime"?
11:47 < sipa> sure
11:47 < sipa> (all sighash currently already commit to nLockTime, though)
11:50 < ariard_> yeah but was thinking about more fine-grained hash_types and you would combined them to have a weak covenant
11:54 < nothingmuch> in bip-schnorr, scalars k and e and are used mod n, the curve order, whereas in bip-taproot t (tap tweak hash) is constrained to be less than n. why is it curve order and not field size? why do these differ? doesn't bip-schnorr footnote 10 apply to all?
11:55 < nothingmuch> "why do these these differ" refers to the difference in handling of k and e vs. t
11:57 < sipa> nothingmuch: it's modulo n because they're all integers modulo n
11:57 < sipa> forgot that we're using elliptic curves
11:57 < sipa> the field size is only relevant to the specific implementation of the elliptic curve we pick
11:58 < sipa> but for anything "higher level" construction (including schnorr signatures and the taproot tweak), all that matters is how many elements there are in that group - which is n
12:01 -!- jonatack_ [~jon@37.165.182.12] has joined ##taproot-bip-review     
12:01 < sipa> ok, have to run
12:01  * devrando1 waves
12:01 < kabaum> Thank you!
12:01 < nothingmuch> thanks
12:01 < jonatack_> thanks
12:01 < aj> #endmeeting
12:02 < lightningbot> Meeting ended Tue Nov 26 20:02:00 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:02 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-26-19.01.html
12:02 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-26-19.01.txt
12:02 < lightningbot> Log:            http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-26-19.01.log.html
12:02 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Quit: leaving]     
12:03 < nothingmuch> hmm, so why is t not mod n?
12:03 < gmaxwell> nothingmuch: scalar's k and e are used to number curve points. There are n curve points (including the point at infinity).
12:04 < gmaxwell> nothingmuch: it is.
12:04 < gmaxwell> Let t = hashTapTweak(p || km).
12:04 < gmaxwell> If t ≥ 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 (order of secp256k1), fail.
12:05 < sipa> i think why nothingmuch is asking why it fails when it overflows, rather than interpreting modulo n
12:05 -!- jonatack [~jon@37.164.112.70] has quit [Ping timeout: 265 seconds]     
12:05 < nothingmuch> yes, and was just trying to figure out how to rephrase it more clearly. thank you!
12:05 < sipa> the answer is it doesn't really matter much - we could make it more consistent actually
12:05 < sipa> because hitting the case is as hard as creating a collision in SHA256
12:06 < gmaxwell> In the case of K  doing anything but rejection sampling would look dangerous, because for other common curves where n isn't very close to a power of 2, doing a mod there creates an exploitable bias.
12:07 < gmaxwell> Other cases don't matter much, though you can debate which handling results in less risk of implementation inconsistency.
12:07 < gmaxwell> I have a general preference for rejection, we've gone back and forth about this in varrious places.
12:09 < sipa> one argument is simply implementation: what do we expect is easiest to implement
12:13 < sipa> gmaxwell: i think there is a distinction between the signing side and verification side
12:13 < sipa> or rather, whether it's on secret values of public values
12:14 < sipa> for secret values (nonce, private key) you must do rejection sampling, so the nonce generation algorithm must fail for out of range values (which for secp256k1 is still unobservable)
12:15 < sipa> for things like e and t which are public and known at verification time, using mod n is possibly simpler than saying they cause failure
12:29 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review     
12:30 < gmaxwell> possibly, though we've seen elsewhere that mod-n isn't always implemented correctly, consistently. Secp256k1's n is close enough to (2^8)^32 that it's probably not a big concern.
12:31 < gmaxwell> But, for example, in ed25519 implementations handle mod n of the scalar in the signature incorrectly after deserializing, resulting in mutiple mutually incompatible implementations some of which accept malleated signatures.
12:31 < midnight> yikes :-/
12:31 < gmaxwell> in any case, I don't mean to argue for one or the other.
12:32 < gmaxwell> From an auditing perspective, the test is easy to look for-- easier than verifying the modular reduction is done correctly, I think... because it's explicit.
12:32 < gmaxwell> The only strong position I have on non-secret values is that important thing is just that it is handled in some intentional way and documented clearly.
12:33 < gmaxwell> For secret values I think its important to use rejection sampling even though n is so close to 2^256,  an auditer shouldn't be burned with having to convince themselves that the statistical distinction is irrelevantly small in all use cases (though I'm convinced of that).
12:53 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
13:20 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
13:31 -!- pyskell [~pyskell@unaffiliated/pyskell] has quit [Quit: Leaving]     
13:36 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review     
13:37 -!- jonatack_ [~jon@37.165.182.12] has quit [Quit: jonatack_]     
13:37 -!- jonatack [~jon@37.165.182.12] has joined ##taproot-bip-review     
13:40 -!- dr-orlovsky [~dr-orlovs@37.46.115.6] has joined ##taproot-bip-review     
13:44 -!- dr-orlovsky [~dr-orlovs@37.46.115.6] has quit [Ping timeout: 265 seconds]     
13:50 -!- dr-orlovsky [~dr-orlovs@37.46.115.6] has joined ##taproot-bip-review     
14:03 -!- dr_orlovsky [~dr-orlovs@2a02:1205:500f:2e90:945d:41d:a690:8c28] has joined ##taproot-bip-review     
14:05 -!- dr-orlovsky [~dr-orlovs@37.46.115.6] has quit [Ping timeout: 240 seconds]     
14:14 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 250 seconds]     
14:19 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]     
14:21 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review     
14:43 -!- b10c [~Thunderbi@mue-88-130-54-176.dsl.tropolys.de] has quit [Ping timeout: 268 seconds]     
15:15 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 265 seconds]     
15:21 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
15:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
15:41 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review     
16:28 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]     
16:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review     
16:57 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 268 seconds]     
16:58 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
17:03 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]     
17:20 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
17:20 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
17:28 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]     
17:41 -!- dongcarl [sid321684@gateway/web/irccloud.com/x-solzrkpkqxpkgmdi] has quit []     
18:18 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review     
18:21 -!- Tibo [7c2353a2@124x35x83x162.ap124.ftth.ucom.ne.jp] has joined ##taproot-bip-review     
18:43 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 250 seconds]     
18:51 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]     
20:29 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-bip-review     
21:50 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review     
21:53 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 265 seconds]     
21:58 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has quit [Ping timeout: 250 seconds]     
23:00 -!- kabaum [~kabaum@185.224.57.161] has joined ##taproot-bip-review     
23:01 -!- Tibo [7c2353a2@124x35x83x162.ap124.ftth.ucom.ne.jp] has quit [Remote host closed the connection]     
23:15 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
23:24 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]     
23:25 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
23:34 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]     
23:55 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
23:59 -!- jonatack [~jon@37.165.182.12] has quit [Read error: Connection reset by peer]