--- Log opened Sun Apr 18 00:00:29 2021 00:09 -!- leevancleef [8074ecf1@128-116-236-241.static.eolo.it] has joined ##taproot-activation 00:42 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation 01:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:18 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 02:04 <@michaelfolkson> robert_spigler: That depends on what activation mechanisms are used in other clients post ST failing. Unless you think there won't be an activation mechanisms in other clients until October 2022. That's a long wait 02:05 <@michaelfolkson> I would guess that most people would rather run BIP 8(LOT=true) assuming ST fails than wait for October 2022 for a new activation release 02:05 <@michaelfolkson> But we'll see, I could be wrong 02:14 <@michaelfolkson> My expectation is that ST activates and we never get to find out whether the network would have run BIP 8 (LOT=true) in the run up to October 2022 (for Taproot at least) 02:53 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 02:55 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 04:43 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 04:44 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-cyzkxkevrbubbkye] has quit [Quit: Connection closed for inactivity] 04:46 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 04:55 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation 04:58 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 05:13 -!- duringo [4a779229@74.119.146.41] has quit [Ping timeout: 240 seconds] 05:15 -!- duringo [ad004d55@173.0.77.85] has joined ##taproot-activation 05:18 <@michaelfolkson> graeme1: I'll take a look. Thanks for the question 05:26 <@michaelfolkson> Also thanks jeremyrubin for updating the mailing list. Meeting scheduled for Tuesday has been cancelled https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018816.html 05:28 -!- duringo [ad004d55@173.0.77.85] has quit [Ping timeout: 240 seconds] 05:42 -!- duringo [5bdbd4e5@91.219.212.229] has joined ##taproot-activation 05:55 -!- leevancleef [8074ecf1@128-116-236-241.static.eolo.it] has quit [Quit: Connection closed] 06:29 -!- mutualp2p [~mutualp2p@ip-178-216.ists.pl] has joined ##taproot-activation 06:36 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 06:36 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 07:04 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 07:05 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 07:06 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:07 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation 07:08 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:09 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:21 < graeme1> michaelfolkson: thanks, yeah I think this will create problems for the UASF users unless the client is updated 07:24 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 07:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 07:25 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 07:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 07:34 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer] 07:35 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 08:07 < faketoshi> robert_spigler: I'd say that is unlikely to happen as many people will still want taproot if ST fails. If it fails because it suddenly looks like a bad idea then 'UASF'ers would no doubt abandon their client 08:10 < mol_> faketoshi, oh yeah? :D 08:11 < queip> faketoshi: sorry, I thought it was said "UASF" is incorrect term in context of Bitcoin Core-based taproot forcing client? 08:11 < faketoshi> That's why I put it in quotes. 08:11 < queip> ok 08:12 < queip> will tho "UASF" be correct in scenario where all other fails to activate and LOT=true comes into effect? 08:13 < faketoshi> There are different opinions on that. imo yes, but luke-jr would argue it's still a MASF just the users reject blocks until the miners decide to flip the bit 08:14 < faketoshi> UEMASF is the most accurate description but people generally view this as a UASF afaict 08:14 < queip> in case of using LOT=true, we reject blocks that are not marked as "in this block evaluate transactions according to taproot rules"? 08:14 < faketoshi> no, blocks are rejected that don't signal activation, this needs to happen priot to actual use of taproot 08:15 < queip> so exactly as in bip148? 08:15 < faketoshi> yes without the alarmingly short time period 08:16 < mol_> it is UASF client though 08:16 < mol_> call it is or UASF supporters won't run it 08:17 < mol_> call it like it is* 08:18 < faketoshi> There are different opinions on that. The name is a sticking piont for so many it seems, including the usage of the word "core" which I would rather have not done. 08:19 < faketoshi> But then again, shaolinfry's client was called | 08:19 < faketoshi> "Bitcoin Core UASF BIP 148" and no one minded 08:19 < faketoshi> Though that may be due to differences in context 08:19 < mol_> i support luke's confusion, the more the better :LOL: 08:29 -!- bcman [~quassel@static-198-54-131-107.cust.tzulo.com] has joined ##taproot-activation 08:32 -!- faketoshi [~quassel@static-198-54-131-171.cust.tzulo.com] has quit [Ping timeout: 268 seconds] 09:00 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation 09:03 -!- bcman is now known as faketoshi 09:05 <@michaelfolkson> You do like trolling don't you mol_? Maybe occasionally write something that is worth reading and not just purely trolling? I don't know, just an idea 09:07 <@michaelfolkson> queip: I personally think it should be called UASF. From what I understand "UASF" was avoided as a name because it triggers anti UASF people from 2017. But then the current "Bitcoin Core based" name triggers pro UASF people from 2017 09:08 < luke-jr> faketoshi: no, I agree the final fallback after 18 months is a UASF; but BIP8 as a whole, and the whole length of time leading up to that, is not 09:10 <@michaelfolkson> Right, it only becomes a UASF at the end of the 18 months. So until then it is miner activated. That too 09:10 < luke-jr> michaelfolkson: how so? seems to me it would only trigger trolls. 09:10 < luke-jr> re 'current "Bitcoin Core based" name triggers pro UASF people from 2017' 09:10 < queip> I think Bitcoin Core based is a good compromise for everyone 09:11 <@michaelfolkson> luke-jr: It is hard to differentiate sometimes between trolls and non-trolls. Some people are clearly trolls :) belcher (who I don't think is, could be wrong) didn't like Bitcoin Core based 09:12 < luke-jr> I don't know what's up with belcher lately 09:14 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 09:16 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Ping timeout: 240 seconds] 09:21 <@michaelfolkson> Supporting a rushed UASF at the end of a BIP 9(1 year) in 2017 but not supporting a well planned UASF at the end of a BIP 8(18 months) for Taproot is hard to explain 09:23 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation 09:23 <@michaelfolkson> I get some people don't like UASFs at all. But belcher supported the UASF in 2017. Doesn't make sense to me 09:24 < queip> belcher: what is your view on that? want to share arguments? 09:27 < mol_> michaelfolkson, im not a good troll like you, no worry i won't take your place 09:29 <@michaelfolkson> queip: In the absence of belcher appearing I think the argument is that for SegWit a UASF was needed and for Taproot it isn't needed. But at the start of the SegWit BIP 9 deployment no one thought a UASF would be needed 09:29 < luke-jr> BIP8 doesn't have a UASF unless it's needed ;) 09:30 <@michaelfolkson> queip: So the only difference here is that it isn't rushed. It isn't actually used if miners signal by themselves 09:30 < faketoshi> graeme1: thanks for taking a look at it. note - it's not luke's client :) 09:30 <@michaelfolkson> luke-jr: Right 09:31 < luke-jr> Activation doesn't require new address formats. 09:31 < harding> luke-jr: are you gonig to merge https://github.com/bitcoin/bips/pull/1104 ? 09:32 < luke-jr> [05:15:35] Have there been any businesses/software implementations/miners yet come out and say they are running the UASF/BIP8? <-- yes, but we should probably work on talking to more and making a nice list 09:34 < jeremyrubin> luke-jr: have y'all considered having a second bit that your client also signals on so that you can estimate who is mining on your client v.s. others? 09:34 < jeremyrubin> I think it would improve information, altho gameable 09:35 < luke-jr> harding: I will do what I am obliged to do, but I haven't look at that PR yet, so can't comment specifically. 09:35 < queip> or rather a bit "I intent to support uasf if it comes to this"? 09:35 < jeremyrubin> more or less, but I don't want it to be "miners decide" 09:35 < luke-jr> jeremyrubin: miners don't decide rules, so I don't see how that would be helpful 09:35 < jeremyrubin> altho you could program your node to, if > 51% signalling, enforce it 09:36 < queip> purely informative bit? 09:36 < harding> luke-jr: when do you expect to look at it? 09:36 < luke-jr> queip: but it's not useful information 09:36 <@michaelfolkson> harding: Is this merge needed or just a nice to have? 09:36 < harding> luke-jr: hours, days, weeks? 09:36 < luke-jr> harding: I try to look through the bips PRs at least once a month, but I don't have a regular schedule 09:36 < jeremyrubin> I think merge is required personally; you can't see open PRs on a document by looking at it 09:37 < harding> luke-jr: ok, I think that's unacceptably slow. Would you consider giving someone else merge access in addition to yours so they can perform simple duties like merging 1104? 09:38 < luke-jr> harding: maybe. I'll have to think about it;. 09:38 < harding> luke-jr: are you deliberately stalling? 09:39 < luke-jr> nope 09:39 < luke-jr> last time I wanted to add another BIP editor, I was met with unexpected objections, so it's not as trivial as it might seem 09:41 < jeremyrubin> can you set a deadline for doing this one? 09:42 <@michaelfolkson> It is a touch complicated if there is disagreement on what the parameters are and what activation BIP is being used. Clearly Core and the BIP authors area in agreement on what the parameters are 09:43 < luke-jr> at the same time, BIP10x didn't have any sort of community support either 09:43 <@michaelfolkson> I think it would be top priority if it was holding up Core progress. But I don't think it is holding up Core. It is just a (very) nice to have 09:43 < luke-jr> harding: what's the rush anyway? 09:44 < harding> luke-jr: in my personal case, I would like to report that the parameters have been added to BIP341 in the same weekly Optech newsletter where I report about them being merged into Bitcoin Core. 09:46 < luke-jr> I see. When is that? 09:48 <@michaelfolkson> luke-jr: Optech goes out Wed but obviously needs to be drafted before that 09:48 < harding> luke-jr: Newsletter is published Wednesday; I plan to finish writing the draft today. Here's our regular writing and publication schedule: https://gist.github.com/harding/0dffdde00761262ca094219c33b8ff22 09:57 < graeme1> luke-jr: were you referring to my comment when you said "Activation doesn't require new address formats" ? It seems reasonable to me that the client should incorporate BIP 350, otherwise users may be confused and not realize they need to upgrade again 09:57 < luke-jr> graeme1: they don't need to upgrade again, though 09:58 < graeme1> but wouldn't any address creation or RPC use in that client use the old segwit address format? 09:59 < luke-jr> The built-in wallet does not support Taproot yet, period. 09:59 < luke-jr> activation is just for the consensus-level feature, not wallet support 09:59 < luke-jr> and Taproot is opt-in - nobody *has* to use it 10:00 < graeme1> ok, so why did core backport BIP 350 since there isn't wallet support in 0.21.1 ST? 10:00 < luke-jr> so 0.21.1 can *send to* Taproot wallets 10:00 < graeme1> I'm just curious btw, not trying to be antagonistic, I'm still learning 10:00 < jeremyrubin> graeme1: it means you probably can't send money to someone who is using a taproot enabled wallet but those don't really exist yet anyways 10:00 < luke-jr> personally, I am of the opinion that it shouldn't have been backported, since it's a feature - but it's not unreasonable to do so either 10:01 < luke-jr> rebasing Taproot Client on 0.21.1 shouldn't be too difficult in any case 10:01 < luke-jr> anyhow, it's not a must-have upgrade for Taproot to activate 10:02 < graeme1> but could the UASF client be used to verify an incoming Taproot transaction following BIP 350? 10:02 < luke-jr> it verifies the blockchain 10:02 < graeme1> even if users aren't using the client as a wallet, presumably most users like to use their own node to verify incoming 10:02 < luke-jr> yes, it can be used for that 10:02 < graeme1> ah ok, thanks 10:02 < luke-jr> without BIP350 even 10:02 < graeme1> that was my worry 10:03 < luke-jr> unless you're trying to use the wallet to verify incoming txs - eg, watchonly wallet 10:03 < luke-jr> that won't work even with BIP350 10:03 < luke-jr> (actually, I could be wrong on that…) 10:08 < graeme1> so I suppose the affected users would be someone who has funds on an internal bitcoin core wallet, that wants to sweep those funds to an external taproot supporting wallet 10:08 < graeme1> which would not be possible with the current UASF client, correct? 10:09 < luke-jr> correct 10:09 < graeme1> they would need to send that transaction from core and not the UASF client 10:09 < graeme1> ok thanks 10:09 < luke-jr> also note this scenario cannot occur until after activation 10:10 < harding> graeme1: it's important not to send funds to a taproot address until after at least several blocks after taproot activates, otherwise those funds can be stolen by anyone (especially miners). 10:10 < graeme1> understood, but presumably someone may download the client and not upgrade again, thinking that they have the taproot feature set 10:10 < graeme1> but they wouldn't actually be able to spend to taproot with that client 10:11 < luke-jr> graeme1: not like anything bad would happen mind you 10:11 < luke-jr> they'd find they can't do it, and presumably upgrade again at that time 10:13 < graeme1> thanks for the info 10:53 -!- contrapumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation 10:55 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Ping timeout: 268 seconds] 11:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 11:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 11:43 <@michaelfolkson> If anyone is unclear on MTP (used in Core's Speedy Trial and previous BIP 9 activations) this may be helpful. I'll try to improve on this answer https://bitcoin.stackexchange.com/questions/105515/what-are-the-differences-between-the-various-mtps-in-bitcoin/ 11:47 < harding> michaelfolkson: there's only one MTP, it's just used in different places. 11:49 < harding> In the main consensus protocol, it's used to prevent miners from creating blocks in the far past (but timewarp can get around this at the cost of being obvious that you're trying to get around it for about a couple weeks before you start seeing any benefit from the attack). 11:50 < harding> Since BIP113 was activated, it's also used for making comparisons to nLockTime when used as a time. 11:51 <@michaelfolkson> harding: Ok thanks, that makes more sense. I was thinking there were 3 different MTPs... 11:55 < harding> For BIP9, it doesn't determine a block height based on MTP; it determines whether it will start or stop measuring signaling based on the current MTP. BIP9 defaults in the past were chosen to give miners about a year to activate a fork, since that's a time range and MTP is a time, and since what people are really interested in is a time, I don't think anyone was putting much effort into predicting specific block heights for things. With ST, 11:55 < harding> that's a bit different because the signaling window is smaller, so carefully choosing dates can give you +/- a signaling period assuming normal block production. 11:57 < harding> Um, to be clear, carefully choosing a traditionaly BIP9 startdate could probably also +/- one signaling period, but it's much less of an issue when you have about 26 periods versus 6. 11:58 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation 11:59 * harding bbl 12:01 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 13:35 < jeremyrubin> harding: it's also not really that much of an issue IMO since I think 4 periods should be sufficient for activation anyways, if miners are purposefully trying to upgrade in the last possible window it's lulzy anyways 13:35 < jeremyrubin> Like it's possible if you're targetting only upgrading your software in the last possible period, it's possible that you hit a snafu for a day or two and then the upgrade misses the window anyways 13:36 -!- duringo [5bdbd4e5@91.219.212.229] has quit [Quit: Connection closed] 13:37 < harding> Right. My point was just that, if you look at BIP68 and BIP141, their dates seem to be just round(ish) numbers (on a calendar), whereas a bit more attention was paid to the BIP341 time parameters. 13:38 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 246 seconds] 13:39 < jeremyrubin> yep 13:39 < jeremyrubin> my feeling is basically that start time doesn't matter that much 13:39 < jeremyrubin> because e.g., we can see there's not signalling on the bit right now 13:39 < harding> Agreed. 13:39 < jeremyrubin> so you can even backdate it if you really wanted 13:40 < jeremyrubin> (esp with minactiveheight) 13:44 < jeremyrubin> i also think (present hashrate snafu excluded) hashrate generally goes up, so for ST height we're more likely to have a week or two less of wall-clock upgrade time, and more likely to gain extra periods 13:44 < jeremyrubin> *more likely to gain extra periods with MTP 13:44 < jeremyrubin> And if hashrate *decreases* markedly, then a slight bias toward non-activation might be prudent as it shows network instability 13:45 < jeremyrubin> so I'm pretty OK with MTP overall for ST 13:45 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation 13:46 -!- Matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 14:02 -!- mips_ [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 14:02 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 14:03 -!- Matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has joined ##taproot-activation 15:01 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 15:01 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation 15:16 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation 15:17 -!- contrapumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Ping timeout: 240 seconds] 16:00 < robert_spigler> luke-jr: re: creating list of businesses supporting UASF 16:01 < robert_spigler> I think that would be helpful for everyone 16:09 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: Hmmm] 16:26 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 16:28 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds] 16:28 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 16:33 -!- GV [4a698cdd@pool-74-105-140-221.nwrknj.fios.verizon.net] has joined ##taproot-activation 16:39 -!- duringo [5bdbd4e5@91.219.212.229] has joined ##taproot-activation 16:42 < queip> BC-BTFC 16:43 < queip> hmm should this project get a bip with some number? to have a number to reference (even if not ever merged by bitcoincore.org's) 16:48 < harding> queip: what project? Taproot-UASF-Nov22? 16:49 < jeremyrubin> luke-jr: out of curiosity what sort of negative feedback did you get about having >1 bip editor? 16:50 < jeremyrubin> I tried to search archives but came up emtpy 16:59 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 17:00 < luke-jr> queip: eh, there's BIP 8. I guess it could have another BIP, but having a BIP just for activation params seems BIP-inflationary 17:01 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in] 17:01 < luke-jr> queip: ideally it'd just be part of the Taproot BIP 17:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 17:05 < queip> harding: hm? this project here it was decide to call it Bitcoin Core-based Taproot [Forcing] Client 17:05 -!- faketoshi [~quassel@static-198-54-131-107.cust.tzulo.com] has quit [Ping timeout: 252 seconds] 17:06 < luke-jr> queip: software doesn't get BIPs 17:06 < queip> luke-jr: we had like... 1.. 2..? such events in past decade 17:06 < queip> luke-jr: not for software, for params 17:06 < luke-jr> queip: BIP148 did have its own BIP, so there's that. 17:06 < queip> yeap 17:06 < luke-jr> queip: want to write one up? :p 17:07 -!- bcman [~quassel@static-198-54-131-107.cust.tzulo.com] has joined ##taproot-activation 17:23 < jeremyrubin> luke-jr: am i muted here? 17:25 < jeremyrubin> (by here I mean IRC) 17:29 -!- belcher_ is now known as belcher 17:30 < jeremyrubin> err i guess i mean (as someone pointed out) do you have me on /ignore -- just checking if I should be relaying any questions through another participant here 17:31 < jeremyrubin> (sorry for the line noise to others in this channel) 18:22 -!- Matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 18:44 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation 18:46 -!- duringo [5bdbd4e5@91.219.212.229] has quit [Ping timeout: 240 seconds] 19:00 -!- queip [~queip@unaffiliated/rezurus] has quit [Read error: Connection reset by peer] 19:11 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation 19:17 -!- GV is now known as GVac 19:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 19:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 20:11 -!- duringo [ad004d11@173.0.77.17] has joined ##taproot-activation 20:40 -!- bcman is now known as faketoshi 20:45 -!- graeme1 [~graeme@gateway/tor-sasl/welkinatdusk] has quit [Quit: WeeChat 3.0] 21:07 -!- GVac [4a698cdd@pool-74-105-140-221.nwrknj.fios.verizon.net] has quit [Quit: Ping timeout (120 seconds)] 21:08 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation 21:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 21:28 -!- mips_ is now known as mips 21:35 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 240 seconds] 21:37 -!- jonatack [~jon@88.127.52.83] has joined ##taproot-activation 22:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 22:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 23:13 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 246 seconds] 23:41 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined ##taproot-activation --- Log closed Mon Apr 19 00:00:30 2021