--- Log opened Tue Mar 30 00:00:11 2021
00:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
00:15 -!- BenPrentice [49eec8c3@c-73-238-200-195.hsd1.ma.comcast.net] has quit [Quit: Connection closed]
00:32 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
00:32 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
00:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]
00:45 -!- andytosh1 [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-activation
00:47 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 260 seconds]
01:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:11 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
02:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
03:18 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
03:30 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
03:41 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
03:49 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
03:49 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
03:53 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
03:53 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
04:05 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 252 seconds]
04:07 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
04:12 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in]
04:18 -!- roconnor [~roconnor@host-184-164-13-101.dyn.295.ca] has joined ##taproot-activation
04:20 < roconnor> aj: having the same activation parameters on signet doesn't mean it activates at the same time as mainnet; thus mainnet could get new rules before signet does.  Syncing up the rules between mainnet and signet requires manual intervention no matter what.
04:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:34 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: setpill]
04:40 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
04:48 -!- belcher_ is now known as belcher
05:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
05:48 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined ##taproot-activation
06:28 -!- p0x [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
06:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
06:31 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
06:32 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
06:32 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:38 -!- stortz [b1982ea0@unaffiliated/stortz] has joined ##taproot-activation
06:38 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
06:38 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
06:41 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
07:42 <@aj> roconnor: it doesn't require manual intervention if you could set an mtp-based flag day activation on signet; it requires manual action only by the signet signers if you can do an mtp-based signalled activation.
07:45 < roconnor> okay, but setting an mtp-based flag day activation in signet isn't an argument for using MTP based ST activation on mainnet.
07:47 <@aj> i don't think an mtp-based flag day on signet makes much sense prior to lock in/activation on mainnet -- it's valuable to have the possibility of running a signet with the exact same rules as mainnet
07:49 <@aj> you could have signalling via mtp on signet and testnet but via height on mainnet, but that doesn't seem simple anymore
07:49 < roconnor> what do you mean by "exact same rule set"  Do you mean the rule set that "if version bits signal in a block period sometime between time A and time B then at a later time C taproot is enforce" or do you mean the exact same rules set as in "at time X taproot rules are enforced"?
07:50 < roconnor> because having taproot unsignaled on signet while signaled on mainnet doesn't strike me as a useful definition of "exact same rule set".
07:50 <@aj> no, as in "this signet only allows scripts/txs that would be valid on mainnet, not new stuff that hasn't actually been deployed yet"
07:51 <@aj> no i mean "except for a small period after new rules are activated on mainnet, the same rules apply on this signet as on mainnet"
07:52 < roconnor> But what scripts/txs would be valid on mainnet is determined by the version bits in mainnet headers, something that signet doesn't have access to.
07:52 < roconnor> oh okay
07:52 < roconnor> That's fair, but that requires manually noting when the rules are activated on mainnet and then adjusting signet.
07:52 < roconnor> which is fine.
07:52 <@aj> "except for a small period (<--- while people update their signet bitcoinds eg) after new rules are activated on mainnet, the same rules apply on this signet as on mainnet"
07:53 < roconnor> but has no bearing on whether to use MTP time for ST activation.
07:53 <@aj> right, but you want other signets to have the rules active prior to mainnet, so you can test out the rules
07:53 < roconnor> Sure, but that can be done with height just as well as with MTP.
07:53 <@aj> but if you make *that* be a flag day, you bring along the other signets that don't want to upgrade faster than mainnet
07:54 <@aj> no, because if you picked heights applicable the default signet, any new custom signet would have to spend weeks mining to catch up to the height
07:55 <@aj> and if you picked a low height, you wouldn't be able to ever reuse signalling bits, because otherwise old signalling would trigger it for every signet
07:56 < roconnor> if you make a default MTP then signets will get taproot activated prior to mainnet activation, dragging along signets that don't want to be dragged along.  If you want to test activation on custom signets you need custom builds (or a more robust signet configuration).
07:56 < roconnor> and if you are doing custom signets you can do custom hieght based activation tests just fine.
07:57 <@aj> huh?
07:57 < roconnor> releasing a default signet signaled activation for taproot doesn't seem reasonable.
07:57 <@aj> are you talking about signalling or flag day?
07:57 < roconnor> signaled.
07:58 <@aj> if you have signalled, it doesn't matter the defaults, no signet gets dragged along without its miners signalling
07:58 <@aj> but that only works if the signalling period is in the future, which you can only do by making it time based
07:59 < roconnor> And you are saying signalling isn't enabled by default?
07:59 <@aj> good question! i'm certainly assuming it
07:59 < roconnor> Is mainnet not signaled by default?
08:00 < roconnor> I'm assuming mainnet is signaled by default, and hence signet would be by virtue of "being as close to mainnet for testing purposes as possible".
08:00 <@aj> gbt indicates it's available for signalling and includes it by default, but afaik no pools actually automatically respect the defaults?
08:02 < roconnor> If we are talking about what pools actually do in practice, then (switching topics for a second) I think the chances of mining pools actually taking advantage of doing testing of activation on testnet is ~ 0%.
08:03 <@aj> i expect any asicboost compatible pool "violates" the bip9 gbt spec by setting bits that are not listed in "vbavailable"
08:05 < roconnor> BIP9 needs to be adjusted to conform to the reality of the world.  No miner is going to go against thier own self-interests just because some words on the internet say they are being naughty.
08:05 <@aj> sure and bip320 support will be merged in bitcoin core any day now too
08:06 < roconnor> If Bitcoin could operate by relying on participants following protocols instead of their own self-intrest, I'd be using Cardano. :D
08:07 <@aj> miners have been following bip320 pretty consistently
08:09 <@aj> both csv and segwit activated on testnet prior to mainnet; csv took 1.5 months to activate on testnet; segwit apparently took 2 weeks to activate on testnet?
08:10 < roconnor> Right. I mean that bip320 should be merged.
08:11 < roconnor> aj: did the mining pools activate csv and segwit on testnet, or just some random people?
08:11 < roconnor> I supposed we are supposed to not know the answer to that.
08:13 < roconnor> due to the broken testnet3 implementaiton I can probably actiave taproot myself on testnet.  How does that help the miners?
08:13 <@aj> i can't even find gossip on reddit from when it activated
08:15 <@aj> ah, there's https://www.reddit.com/r/btc/comments/4lavfm/despite_being_claimed_as_a_scaling_solution/ i guess
08:16 <@aj> is there any easy way to get at pools' coinbase tags?
08:19 < roconnor> there is very much merit in activating taproot on testnet, but this could be done as a flag day for testnet.
08:20 < roconnor> My question is more about the merits testing the activation method itself on testnet.
08:21 <@aj> okay, segwit activated on testnet before being merged into core
08:22 <@aj> https://bitcoincore.org/en/2016/06/24/segwit-next-steps/
08:22 <@aj> i don't see how you could do it on testnet as a flag day by height?
08:23 <@aj> well... i didn't, i guess it couldn't be any worse than segwit activating before even being released?
08:23 < roconnor> doesn't have to be by height.  Doing a MTP flag day activation on testnet would be fine.
08:24 < roconnor> Doing a MTP flagday on testnet wouldn't have any particular relevence as to whether ST activation should be MTP based or height based.
08:24 <@aj> for heights; i don't see how you could pick a height at a reasonable point in the future so that a reasonable number of testnet users could update to it before it's reached
08:25 <@aj> but maybe segwit demonstrates that's just necessary
08:25 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
08:25 <@aj> just not necessary
08:26 < roconnor> Avoiding forking testnet isn't alll that important.  I personally forked testnet2.
08:33 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
08:40 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
08:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection timed out]
08:50 <@aj> "forking" seems a bad word to use there, though a better one isn't coming to mind
08:51 < stortz> cloned?
08:52 < roconnor> consensus failure?
08:53 <@aj> if you don't care about kinda-breaking testnet like that though, doesn't that make it easy to choose signalling values? current-height to current-height + 200,000 eg would be a year on average on testnet, so likely less in practice, or at most 4 years if blocks were 10min
08:53 <@aj> still impossible to choose a min_activation_height though i suppose
08:54 <@aj> (though by the kinda-breaking assumption, that doesn't matter)
08:54 < roconnor> I would just flag day activate on testnet.
08:54 <@aj> flag day activating would be more annoying code changes
08:55 <@aj> and signalling would be more predictable than a flag day height
08:56 <@aj> (all the blocks on testnet for signet's signalling, locked in and first active period, and a bunch around them, were all mined to the same coinbase address)
08:56 < roconnor> *lol*
08:57 < roconnor> I think that suggests one entity was responsible.
08:57 <@aj> not a big surprise considering the code hadn't been merged
08:58 <@aj> all the blocks signalling for csv were mined to the same address
08:59 <@aj> (ie, the same, same address)
09:03 < roconnor> as in the same as the segwit?
09:07 <@aj> yes
09:07 < roconnor> okay.
09:08 < roconnor> makes me think that "testing" the activation method on testnet is pretty low value.
09:09 < achow101> do we know who that miner was?
09:11 < stortz> could we try to simulate a messier testnet environment? e.g. assign malicious intent to certain actors and try to mimic a 'worst case scenario'
09:11 < stortz> and then attempt the activation method
09:12 < roconnor> certainly testing various activation scenarios on regtest is something that should be done (and I understand has been done).
09:14 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Quit: bye]
09:15 <@aj> stortz: signet's meant to be the answer for that, since you don't risk all your blocks getting reorged anytime someone decides to test an asic
09:16 < stortz> alright
09:17 <@aj> stortz: (only difference between signet / regtest for that scenario is that you allow random other nodes to connect to yours for incoming txs eg, whereas if you did that for regtest, anyone could reorg your chain)
09:19 < achow101> I am still of the opinion that we should kill testnet3
09:20 < roconnor> at the very least we should restart a testnet without the difficulty bug.
09:21 <@aj> difficulty bug?
09:21 < roconnor> https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
09:22 < roconnor> > Thus, on testnet when the block before the retarget (block #2015, #4031, etc) is a difficulty 1 block due to the special minimum difficulty rule, the retarget logic for the next block will run based upon the assumption that the difficulty for the entire previous 2015 blocks has been 1!
09:22 < achow101> I thought that was intentional
09:23 < roconnor> > And because a retarget is bounded to never increase the "current difficulty" by more than 4X, the new difficulty will be recalculated to be either 1, 2, 3, or 4.
09:23 < roconnor> I think it was never intentional to bring down the difficulty of the next retargetting peroid to 4.
09:24 < roconnor> just to make only the next block have low difficulty.
09:25 < roconnor> That said the 20 minute rule is also very bad.  But this bug bringing down the difficulty is even worse.
09:26 < jeremyrubin> I don't think it's worth the engineering effort to fix
09:26 < jeremyrubin> now that we have signet why bother with testnet at all?
09:27 <@aj> so miners can test their asics?
09:27 <@aj> though not clear why you wouldn't just test against mainnet and avoid wasting electricity
09:28 <@aj> i guess if you're a pool, checking that when you find a block it actually gets published is worth doing off of mainnet in case you actually have bugs
09:28 < jeremyrubin> why tho?
09:29 < jeremyrubin> I guess you can find a block more likely?
09:29 < jeremyrubin> so you spend less time mining invalid?
09:30 <@aj> if you want to test what happens when you find a valid block, you have to find a valid block first, and easier to do that on testnet, especially if difficulty is 1?
09:31 < jeremyrubin> But can you not do the same with your own signet?
09:32 < achow101> test on regtest?
09:32 <@aj> bunch more work to setup your own signet than just point at testnet, even given syncing time?
09:32 <@aj> hard to mine an invalid block on regtest, might not be a very good test
09:33 <@aj> (might also be a bold assumption that pools need/care to do much testing)
09:33 < achow101> the block header validity rules are all the same... the actual pow doesn't matter
09:33 < achow101> and I don't think testing that you can make pow invalid headers is useful
09:33 < achow101> (you can test that on mainnet)
09:35 <@aj> pools are meant to figure out which headers are valid/invalid, testing that they get that right seems pretty essential; if they get it wrong on mainnet, their hashpower is going to go elsewhere, or they're giving out rewards to users that didn't do enough work...
09:39 < achow101> aj: do you still approach nack 21392?
09:42 <@aj> achow101: i'm thinking more about what signet activation could look like in future (for CTV/ANYPREVOUT/etc... ugh, for consensus-cleanup too i suppose), which is to say i don't currently have an answer for that question
09:47 <@aj> afaics min_activation_height is only useful on mainnet; min_lockin_time could be used on testnet but isn't needed; neither have any point on any signet because the signing nodes are all the enforcement that's needed, and presumably won't start signalling until they're enforcing
10:26 -!- stortz [b1982ea0@unaffiliated/stortz] has quit [Ping timeout: 240 seconds]
10:46 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
10:48 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Quit: jonatack]
11:01 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
11:27 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 268 seconds]
11:29 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
12:02 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
12:03 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
12:15 < devrandom> hmm... isn't there a meeting?  it's 19:15 UTC
12:18 < achow101> devrandom: it's every 2 weeks
12:18 < achow101> so next week
12:23 < devrandom> so the topic should be updated ;)
12:26 < devrandom> aj: michaelfolkson: topic is out of sync with actual meeting schedule
12:28 -!- michaelfolkson changed the topic of ##taproot-activation to: Biweekly meeting to discuss Speedy Trial activation on Tuesdays at 19:00 UTC Logs: http://gnusha.org/taproot-activation/ Development of a LOT=true implementation belongs in ##uasf. Discussion on Taproot itself belongs in ##taproot-bip-review.
12:28 <@michaelfolkson> devrandom: Thanks, updated
12:29 < devrandom> thank you
13:11 -!- stortz [bb3fa18c@unaffiliated/stortz] has joined ##taproot-activation
13:26 -!- stortz62 [bb3fa18c@unaffiliated/stortz] has joined ##taproot-activation
13:27 -!- stortz62 [bb3fa18c@unaffiliated/stortz] has quit [Client Quit]
13:27 -!- stortz73 [bb3fa18c@unaffiliated/stortz] has joined ##taproot-activation
13:28 -!- stortz [bb3fa18c@unaffiliated/stortz] has quit [Ping timeout: 240 seconds]
13:28 -!- stortz73 is now known as stortz
13:29 -!- stortz [bb3fa18c@unaffiliated/stortz] has quit [Client Quit]
14:00 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 240 seconds]
14:02 -!- cguida [~Adium@2806:2f0:51c1:5cee:fc56:cb9:7a31:8df5] has joined ##taproot-activation
14:04 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
14:05 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:6046:4758:e23d:629a] has quit [Ping timeout: 240 seconds]
14:56 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
15:23 < roasbeef> re testnet vs signet from my PoV signet seems a bit over represented perhaps in this group?
15:23 < roasbeef> every bitcoin system deployed today can already interact w/ testnet while they need to be extended to also add signet support
15:24 < roasbeef> testnet is public, while "signet" is essentially a private regtest instance from my PoV
15:24 < roasbeef> it's nice to give ppl access to script related changes to quickly iterate on though imo
15:37 -!- michaelfolkson2 [~michaelfo@2a03:b0c0:1:e0::23d:d001] has joined ##taproot-activation
15:39 -!- contrapumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation
15:40 -!- phantomcircuit_ [~phantomci@2604:a880:1:20::f2:c001] has joined ##taproot-activation
15:40 -!- aj_ [aj@cerulean.erisian.com.au] has joined ##taproot-activation
15:40 -!- mode/##taproot-activation [+o aj_] by ChanServ
15:41 -!- rabidus_ [~rabidus@dsl-olubng12-54fa17-92.dhcp.inet.fi] has joined ##taproot-activation
15:41 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 265 seconds]
15:41 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Ping timeout: 265 seconds]
15:41 -!- matt2 [~matt@178.128.230.221] has quit [Ping timeout: 265 seconds]
15:41 -!- phantomcircuit [~phantomci@192.241.205.97] has quit [Ping timeout: 265 seconds]
15:41 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined ##taproot-activation
15:42 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
15:42 -!- matt2 [~matt@178.128.230.221] has joined ##taproot-activation
15:42 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Ping timeout: 265 seconds]
15:43 -!- michaelfolkson [~michaelfo@161.35.37.66] has quit [Quit: ZNC 1.8.0 - https://znc.in]
15:43 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 240 seconds]
15:43 -!- rabidus [~rabidus@dsl-olubng12-54fa17-92.dhcp.inet.fi] has quit [Ping timeout: 240 seconds]
16:09 -!- contrapumpkin is now known as copumpkin
16:18 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 246 seconds]
16:41 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
16:45 -!- mode/##taproot-activation [+o michaelfolkson2] by ChanServ
16:52 -!- BenPrentice [49eec8c3@c-73-238-200-195.hsd1.ma.comcast.net] has joined ##taproot-activation
16:53 -!- BenPrentice [49eec8c3@c-73-238-200-195.hsd1.ma.comcast.net] has quit [Client Quit]
17:10 -!- test3423423 [427392a4@66.115.146.164] has joined ##taproot-activation
17:11 -!- test3423423 [427392a4@66.115.146.164] has quit [Client Quit]
17:23 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 240 seconds]
17:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:39 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Read error: Connection reset by peer]
17:40 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
17:52 -!- phantomcircuit_ is now known as phantomcircuit
18:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
18:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:43 < harding> roasbeef: I think it's useful to distinguish the Bitcoin Core default signet (what I like to call "signet prime" in my head) from the signet protocol that allows easily creating independent signets.  If we only consider signet prime, then I agree it doesn't warrant overmuch consideration since we can probably change the code in Bitcoin Core as needed and that signet has two highly competent administrators (aj and kallewoof).  But if we
18:43 < harding> consider other signets run by other people who want to do the immensely beneficial work of testing improvements on a semi-public network, I think it's useful to give extra weight to keeping that mechanism smoothly functioning without placing undue burdens on those other network's administrators.
19:02 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 240 seconds]
19:11 -!- aj_ is now known as aj
19:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]
19:57 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
20:20 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
20:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
20:35 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
20:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
20:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:12 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
21:58 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: Bye!]
21:59 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation
22:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
--- Log closed Wed Mar 31 00:00:12 2021