--- Log opened Mon Feb 22 00:00:37 2021
01:05 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
01:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
01:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
01:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
01:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
02:27 <@michaelfolkson> I think unlikely chain split scenarios (and how the software should deal with them, if at all) should be not within the scope of Tuesday's code review. It will just degenerate into the same LOT conversation
02:30 < aj> knowing how the code does behave, and specific improvements in how it should behave would be on-topic imo
02:30 <@michaelfolkson> Naturally occurring re-orgs are within scope, chain split scenarios with part of the network enforcing forced signaling and part of the network not enforcing forced signaling is not in the scope?
02:31 < aj> having some not-updated nodes on the network, and some blocks that are invalid due to not-updated miners or malicious miners seems in scope
02:33 < aj> for bip148 the goal was to have it work even if only a small part of the network and ~10%-20% of hashpower adopted it; i'm not sure that that's a goal this time
02:34 <@michaelfolkson> Ok I won't try reducing that scope then. But let it be on record that I warned of it degenerating into the same LOT conversation :)
02:38 <@michaelfolkson> Matt's comment here is that LOT=true shouldn't be an option in BIP 8 and/or shouldn't be implemented in the BIP 8 code
02:38 <@michaelfolkson> https://github.com/bitcoin/bitcoin/pull/19573#issuecomment-783141614
02:38 < aj> i think there's a difference between "we know how this code behaves" and "we like how this code behaves" -- should be able to cover the former without the latter
02:40 <@michaelfolkson> Handling chain splits gracefully is impossible in software
02:40 < aj> I read that comment as saying we should consider including more networking code
02:41 <@michaelfolkson> "to handle the network forking"
02:42 < aj> which is another way of saying "some blocks that are invalid due to not-updated miners or malicious miners"
02:42 <@michaelfolkson> Networking code isn't going to save you if you are running protocol rules that aren't in consensus with the rest of the network
02:44 <@michaelfolkson> Those not-updated miners or malicious miners' blocks get re-orged out as far as I can make out. We can already handle re-orgs
02:44 < aj> if you have 60% of hashpower enforcing the rules, 40% of hashpower doing the opposite, but your 60% is split up into two blocks of 30% only connected via nodes running lockinontimeout=false; then once the 40% gets two-blocks ahead, blocks from one 30% won't be relayed to the other 30% and you'll have three chains, one with activation blocked at 40% hashpower, two with activation enabled each at
02:44 < aj> 30% hashpower
02:45 <@michaelfolkson> (If they get accepted at all)
02:45 < aj> networking code can save you from that by having the lockinontimeout=true nodes preferentially connect to each other
02:46 <@michaelfolkson> Cool, thanks. I didn't pick up that scenario
02:46 < aj> right, that's what code review is for
02:47 <@michaelfolkson> Ok that is definitely within scope, agreed
03:05 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
03:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
03:12 <@michaelfolkson> How do you want to structure Tuesday aj? Commit by commit starting with non-test commits?
03:32 < aj> no opinion; not sure i'll make it given the other things scheduled for my tuesday night
03:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:45 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
03:54 <@michaelfolkson> Well if anyone wants to do it let me know. I can always cancel otherwise
04:38 < darosior> michaelfolkson: i'll be present, and re your concern above i'll keep any debate on LOT outside of this meeting :)
04:40 <@michaelfolkson> darosior: Ok it may just be us two at this rate but that's ok :)
05:07 <@michaelfolkson> I think this is the best resource for guidance on reviewing Bitcoin Core PRs for those who haven't attended PR review clubs https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core
05:10 <@michaelfolkson> Personally I only like to ACK the PR when I'm convinced it couldn't be improved, I understand what it is doing and I'm reasonably confident there aren't bugs
05:11 <@michaelfolkson> So blind ACKs from new contributors, reviewers aren't that helpful unless you outline exactly what you've done to assure yourself that the PR is ready to be ACKed and (at least from your perspective) it is ready to be merged
05:13 <@michaelfolkson> It is pretty long (almost 3 hours) but this is a great watch to see how Andrew Chow reviewed the Taproot PR before it was eventually merged https://www.twitch.tv/videos/828581367
05:14 <@michaelfolkson> Obviously a new contributor/reviewer wouldn't be expected to go into that level of detail or understand the codebase as well as Andrew does
05:18 <@michaelfolkson> If anyone does anything either today or tomorrow re reviewing the PR in advance of tomorrow's meeting post it here and we can discuss
05:19 <@michaelfolkson> It is a much smaller PR than the Taproot PR Andrew reviewed in that Twitch video
05:28 <@michaelfolkson> And if you'd rather look at Python than C++ aj has written a functional test to check that the C++ code is doing what it should be doing https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8
05:46 <@michaelfolkson> Alternatively you can look for where the state transitions from the BIP are defined in the C++ code https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#state-transitions
06:20 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##taproot-activation
06:52 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
07:06 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Read error: Connection reset by peer]
07:06 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
08:02 -!- belcher_ is now known as belcher
09:38 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
10:15 <@michaelfolkson> A lot of emails on the dev mailing list but not much new stuff from what I can work out
10:16 <@michaelfolkson> There are a couple of interested convos between Matt and aj
10:16 <@michaelfolkson> *interesting
10:16 <@michaelfolkson> "With the current proposed bip8 code, lockinontimeout=true will cause headers to be marked as invalid, and won't process the block further. If a node running lockinontimeout=true accepts the header, then it will apply the same consensus rules as a
10:16 <@michaelfolkson> lockinontimeout=false node."
10:17 <@michaelfolkson> "I don't think an invalid header will be added to the block index at all, so a node restart should always cleanly allow it to be reconsidered."
10:17 <@michaelfolkson> The test case in https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8
10:18 <@michaelfolkson> "tests that a node that had rejected a chain due to lockinontimeout=true will reorg to that chain after being restarted as a byproduct of the way it tests different cases (the nodes set a new startheight, but retain
10:18 <@michaelfolkson> their lockinontimeout settings)."
10:18 <@michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018460.html
10:19 <@michaelfolkson> And P2P banning concerns in case of lot=true and lot=false nodes on the network: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018464.html
10:20 < luke-jr> michaelfolkson: this is all premised on an assumption that users could safely change LOT after lock-in, which is clearly not intended
10:20 < luke-jr> and also easily fixed
10:21 < luke-jr> all the code already exists for Segwit
10:21 < luke-jr> would just need rebasing and simplification (Taproot isn't as complex as Segwit)
10:21 <@michaelfolkson> Ok cool, thanks
10:21 < luke-jr> but yes, this is part of why an option is worse than just LOT=true all over
10:23 <@michaelfolkson> These arguments apply even if an option isn't offered say in Core. They apply in any scenario where there are some LOT=true nodes and some LOT=false nodes on the network
10:23 <@michaelfolkson> If Core releases lot=false and the community releases lot=true (or vice versa) these arguments also apply
10:23 < stortz> so having the user choose is worse than setting either LOT=F or LOT=T
10:24 < luke-jr> michaelfolkson: right
10:24 < luke-jr> michaelfolkson: or even if Core doesn't release anythign
10:24 <@michaelfolkson> stortz: Having Core get users to choose with no default is the worst option of them all
10:25 <@michaelfolkson> (imo)
10:25 < luke-jr> michaelfolkson: depends on the circumstances
10:25 <@michaelfolkson> But again we are straying back into the LOT discussion I'm trying my best to avoid
10:25 < luke-jr> fwiw the upgrade code from no-Segwit to Segwit was JUST removed in Core after 0.21
10:30 < luke-jr> actually, it might be easier to rewrite for BIP8 from scratch
10:30 < stortz> so considering the no-segwit wasn't re-implemented, we can guess the same will happen with taproot? once people activate it, they won't de-activate
10:30 < luke-jr> stortz: ?
10:31 < stortz> " upgrade code from no-Segwit to Segwit was JUST removed in Core after 0.21"
10:33 < stortz> are you really thinking about rewriting BIP8
10:34 <@michaelfolkson> I think you are misunderstanding Luke's point stortz but I'm not clear either on what he is talking about
10:34 < stortz> yea I think I'm misunderstanding it
10:35 <@michaelfolkson> "upgrade code from no-Segwit to Segwit" If you are running a pre-SegWit version you are treating SegWit transactions as anyone can spend. But the way to fix this is to run a post SegWit version
10:35 <@michaelfolkson> I don't know why you need "upgrade code" when you could just upgrade to a post SegWit version
10:39 <@michaelfolkson> Maybe re-validating SegWit transactions post upgrading to a post SegWit version you previously validated as anyone can spend? I'm not sure...
10:39 <@michaelfolkson> This stuff is hard lol
10:42 < luke-jr> michaelfolkson: that only works because of this code
10:42 < luke-jr> a non-Segwit node doesn't have the full blocks for Segwit blocks
10:43 < luke-jr> so when you upgrade, it needs to detect that, rewind your chain, and re-sync starting with segwit
10:43 < luke-jr> to ensure it downloads the full blocks
10:43 < luke-jr> if a non-Taproot chain were to exist with majority hashrate, you would also need similar logic to switch to the Taproot chain after the fact
10:43 < luke-jr> but that's unlikely to occur
10:44 < stortz> ok I think I understand
10:45 <@michaelfolkson> Why do you need to "properly validate" for a second time blocks you previously validated as valid anyone can spend? I guess it is more conservative
10:46 <@michaelfolkson> I just assumed you didn't go back and "properly validate" them. You validated them as anyone can spend at the time and you were happy not to go back to them
10:48 <@michaelfolkson> Again I'm failing a bit with language here. A block post the SegWit upgrade would have both SegWit and non-SegWit transactions. If you were running a pre-SegWit version then you would be doing full validation on the non-SegWit transactions but treating SegWit transactions as anyone can spend. Which means you aren't doing full validation on the SegWit transactions at the time
10:49 <@michaelfolkson> This upgrade code Luke is talking about is ensuring you go back to those SegWit transactions once you have upgraded to a post SegWit version and doing full validation on them (you previously treated them as anyone can spend)
10:51 < sdaftuar> michaelfolkson: in the context of segwit, full (non-pruning) nodes need to rewind the chain back to the first segwit block, so that they can redownload those blocks with witnesses.  otherwise, when other nodes are trying to fetch old blocks you'd give them the non-witness version, which would be bad (they'd fail validation under segwit rules)
10:52 < sdaftuar> that is a unique property of segwit, because it introduced a new serialization for blocks with witnesses
10:52 < sdaftuar> however the broader point is that it is more conservative to revalidate old blocks with the new rules if they weren't validated under the new rules the first time, to ensure you're not on an invalid chain
10:53 < stortz> so the same won't be needed for taproot with pay-to-taproot-script, correct?
10:53 < sdaftuar> i haven't been following this conversation super closely but i believe you guys are talking about a situation where there is a chain split, and what happens when a node tries to switch from one set of consensus rules to another
10:54 < stortz> we were talking about the  "upgrade code from no-Segwit to Segwit" and how it relates to taproot upgrade
10:54 <@michaelfolkson> Ah of course. You don't have the witnesses if you were previously running a pre-SegWit version. D'oh. Thanks sdaftuar
10:54 <@michaelfolkson> So you need to go get them
10:55 < sdaftuar> michaelfolkson: right -- if you look back at the code that was removed (RewindBlockIndex, i think the function was called), you'll see that for pruning nodes, we just rewound to the last block that was present (since that's as far back as we can disconnect)
10:55 < sdaftuar> this ensured that pruning nodes that upgraded after segwit activation didn't have any non-segwit blocks they might possibly give to anyone else, but we didn't go as far as requiring all pruning nodes that upgraded after segwit activation to go back and revalidate the whole chain
10:56 < sdaftuar> which would have been pretty annoying -- basically it means syncing from scratch
10:56 < sdaftuar> stortz: i think luke was talking about a scenario where there are two competing chains, a non-taproot one with majority hashpower, and a taproot-enabled one with minority hashpower, and what happens when a node switches from the former to the latter
10:58 <@michaelfolkson> So with Taproot there are versions that don't know about SegWit versioning at all (pre 0.16) and versions that only know how SegWit version 0 is defined and not SegWit version 1 (Taproot)
10:59 < sdaftuar> michaelfolkson: 0.13.1 is the first bitcoin core version that supports segwit (not 0.16)
11:00 <@michaelfolkson> But it sounds like with Luke saying that upgrade code has been removed we are no longer worried about pre SegWit versions upgrading and doing full validation on those SegWit transactions they previously treated as anyone can spend
11:00 <@michaelfolkson> sdaftuar: Thanks for that correction
11:01 < sdaftuar> that code was removed because at this point, if you tried to upgrade a node that has been running this whole time under pre-segwit validation, you're better off just starting from scratch anyway -- it's faster than disconnecting all those blocks and reconnecting
11:03 <@michaelfolkson> But we will need similar upgrade code for pre-Taproot versions (they know about SegWit versioning but not about SegWit v1 witnesses). When they upgrade to a Taproot version they will need to fetch and revalidate v1 witnesses they previously treated as anyone can spend
11:03 < sdaftuar> michaelfolkson: i think it would be nice if we had that kind of enforcement for all soft forks, but whether and to what extent it is needed depends a lot on how activation goes i think
11:05 < sdaftuar> nice, because then you know that you're always on a chain that you've fully validated, even if you upgrade late.  necessary, if we end up in some of these crazy fork scenarios that could result with a reckless activation proposal
11:11 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
11:13 < maybehuman> So if I understand correctly, switching LOT after lock-in is unsupported. What would happen if I tried? Is there code to prevent this and show a hopefully helpful error, or will it just break in mysterious ways?
11:13 < maybehuman> and what is the recommended way to switch after lock-in then, resync from genesis?
11:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
11:18 <@michaelfolkson> I find it highly unlikely that Core will support the user choosing the LOT default or switching LOT at a later date
11:18 <@michaelfolkson> If you try it you are on your own
11:19 < maybehuman> so does that mean it would be hardcoded or would there be some code that detects if you try to change it after lock-in?
11:20 <@michaelfolkson> The default would be set like other defaults (block reward) are set
11:21 <@michaelfolkson> In theory you could change your Core software to accept blocks with a 100 BTC block reward. Don't expect Core to save you though if you get forked off the chain
11:22 < maybehuman> ok, cool, so the "make the user choose" option is off the table then. Whew :-)
11:25 <@michaelfolkson> What Core could do in the scenario where the default set in a Core release wasn't being run by anyone (or a minority of the network) is recognize that the default they initially pushed in a release ended up being on the wrong side of consensus and then release a new version with a different default
11:25 <@michaelfolkson> But we really are exploring unlikely scenarios now (to be clear)
11:26 < maybehuman> btw, I wonder how the preferential peering stuff would scale if there are at some point multiple softforks in progress at the same time (which was a design goal with version bits I think)
11:27 <@michaelfolkson> Ha. The more I try to understand this the more I start to realize one soft fork at a time is moooooore than enough
11:28 < maybehuman> or one LOT setting ;-)
11:28 <@michaelfolkson> Imagine having this LOT discussion on two or three different soft forks at the same time haha
11:32 <@michaelfolkson> We are worried about the chain split scenario with one soft fork and two (contentious) LOT options. If you increase the number of soft forks at the same time or number of contentious parameters the risk of that chain split goes way up
11:32 < maybehuman> well, I think in 2016 (or whenever it was written), bip authors were probably still naive and full of hope :-)
11:33 <@michaelfolkson> 2017 killed a lot of expectations on the levels of complexity that are manageable, right
11:33 < maybehuman> although in theory they were right, softforks don't really take anything away from people not using them, and if they're functionally independent why not
11:34 < maybehuman> but yes, there's the review & management bottleneck
11:35 < maybehuman> sorry for beating the apparently dead horse again, but this chainsplit problem would go away if the lot parameter didn't exist, right?
11:36 <@michaelfolkson> In theory yes. If you could guarantee there wouldn't be UASF attempts (which you can't)
11:37 < maybehuman> ok, so because some people threaten a chainsplit by UASF, the rest have no choice but to follow (to avoid the risk)
11:38 <@michaelfolkson> It is emotive language you are using. Some people think lot=true is superior and the lot=false people are threatening a chainsplit
11:38 -!- manj-gnome [~manjaro-g@37.161.8.9] has joined ##taproot-activation
11:38 <@michaelfolkson> Most of the arguments are symmetric depending on which side you are on
11:39 < maybehuman> yes, I just wanted to make it a bit more understandable, no outrage intended. But from the point of view of the status quo, it would be the true side (as it was in 2017)
11:39 <@michaelfolkson> (I say without referring back to the T1-T6 and F1-F7 arguments)
11:40 < maybehuman> (status quo as in deployed software)
11:41 <@michaelfolkson> The precedent from SegWit was lot=false set as the default and then a non-BIP 8 UASF being attempted at the end of the 1 year
11:41 <@michaelfolkson> But pretty much everyone agrees 2017 was an (arguably unavoidable) mess
11:42 -!- manj-gnome [~manjaro-g@37.161.8.9] has quit [Client Quit]
11:42 < luke-jr> the precedent from Segwit was LOT=false failing, and needing to be set LOT=true
11:42 -!- realname192 [~real@37.161.8.9] has joined ##taproot-activation
11:42 < luke-jr> to fix the bug
11:42 < luke-jr> there is no reason to think LOT would revert back afterward
11:42 < luke-jr> after all, we don't release 0.21 with the inflation bug again, and hope it doesn't need to be fixed because we can trust miners
11:43 < luke-jr> no, we just fix it and keep it fixed
11:44 <@michaelfolkson> "sorry for beating the apparently dead horse again" we're back to beating the horse. Let's try to delay the beating of the horse until after Tuesday's code review
11:45 < luke-jr> +1
11:45 -!- realname192 [~real@37.161.8.9] has quit [Client Quit]
11:45 < maybehuman> michaelfolkson agreed, I'll be good! (but "revert back" would imply it ever changed in most deployed systems :-))
11:47 < maybehuman> btw, one small typo: The pr still says bip9 was removed in v0.21.0, should probably be chaned to .1 as in the line above
11:47 < luke-jr> doh
11:48 < luke-jr> fixed, thanks
11:49 <@michaelfolkson> Achievement badge to maybehuman for first comment specifically on the PR on this channel :)
11:49 < maybehuman> yeehaw!
11:52 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
11:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
12:11 <@michaelfolkson> It would be cool to do the aj suggestion on the mailing list of doing dress rehearsal Taproot activations on Signet
12:28 < luke-jr> I don't see how that reherses anything
12:28 < luke-jr> also Signet has Taproot active
12:30 < luke-jr> disclaimer: I don't see the point of Signet in the first place.
12:34 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
12:38 < robert_spigler> sdaftuar: "that code was removed because at this point, if you tried to upgrade a node that has been running this whole time under pre-segwit validation, you're better off just starting from scratch anyway" - Is this what is done now? Pre segwit nodes that upgrade revalidate the entire chain? Can someone link me to the PR that removed the upgrade code?
12:40 < robert_spigler> Has there been discussion on upgrade code v0->v1 nodes that update later for taproot?
12:40 < luke-jr> robert_spigler: aside from Segwit's special case, we've never done anything special
12:41 < luke-jr> https://github.com/bitcoin/bitcoin/pull/21009 it's actually not merged yet
12:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds]
13:03 < robert_spigler> luke-jr thanks.  Why would this not be needed for taproot upgrade? Wouldn't nodes have blocks w/ transactions that weren't fully validated?
13:04 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined ##taproot-activation
13:06 < luke-jr> robert_spigler: but they'd be on the right chain anyway
13:06 < luke-jr> it's just like having a short-term assumevalid
13:06 < luke-jr> if there's chain split schnanigans, ofc that changes things
13:13 <@michaelfolkson> The question is why do we care about nodes going back and essentially revalidating SegWit transactions but we don't care about nodes going back and essentially revalidating Taproot  transactions?
13:13 <@michaelfolkson> I'd guess the reason for doing the former is the same as for the latter
13:13 < robert_spigler> luke-jr makes sense
13:14 <@michaelfolkson> You previously validated Taproot transactions as anyone can spend and so (out of conservatism) when you upgrade to a post Taproot version you should also revalidate those same Taproot transactions
13:14 < luke-jr> michaelfolkson: it wasn't about revalidating Segwit, it was about downloading the full block
13:15 < luke-jr> Taproot doesn't have such a discrepancy
13:15 < luke-jr> the blocks aren't changing
13:15 < robert_spigler> If you wanted to be conservative you could reindex?
13:16 <@michaelfolkson> You are storing the v1 witnesses you just aren't validating them (with a post SegWit but pre Taproot version)
13:16 < luke-jr> robert_spigler: you could
13:16 < luke-jr> michaelfolkson: with Segwit, you weren't storing them either
13:16 < robert_spigler> or update in time
13:16 <@michaelfolkson> luke-jr: Ok understood
13:17 < luke-jr> robert_spigler: indeed, there's a 2 week period you know Taproot will be active after :p
13:17 < luke-jr> well, 1 year in the case of LOT
13:17 < robert_spigler> luke-jr yes :)
13:27 <@michaelfolkson> Updated this Stack Exchange answer based on what I have understood from luke-jr and sdaftuar explanations https://bitcoin.stackexchange.com/questions/99431/if-i-delay-upgrading-to-the-latest-bitcoin-core-version-post-taproot-activation
14:03 -!- brg444_ [uid207215@gateway/web/irccloud.com/x-rxlsvubfdfptqvib] has joined ##taproot-activation
14:41 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
15:21 -!- yunier2002 [~yunier200@c-73-85-126-91.hsd1.fl.comcast.net] has left ##taproot-activation []
15:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
15:46 -!- dr_orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 256 seconds]
15:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
15:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer]
16:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
16:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
17:25 -!- amptwo__ [~amptwo@36.78.202.57] has joined ##taproot-activation
17:51 -!- brg444_ [uid207215@gateway/web/irccloud.com/x-rxlsvubfdfptqvib] has quit [Quit: Connection closed for inactivity]
18:10 -!- amptwo__ [~amptwo@36.78.202.57] has quit [Quit: Leaving]
18:27 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
20:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds]
20:16 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
20:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:20 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
21:21 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
21:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
21:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
21:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:51 -!- pox [~pox@141.226.243.49] has quit [Quit: pox]
23:51 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined ##taproot-activation
23:51 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation
--- Log closed Tue Feb 23 00:00:37 2021