--- Log opened Wed Nov 24 00:00:42 2021 00:05 -!- pinheadmz [~pinheadmz@hns-contributor.dev] has joined #bitcoin-core-pr-reviews 00:06 -!- pinheadmz_ [~pinheadmz@hns-contributor.dev] has quit [Ping timeout: 264 seconds] 00:12 -!- seaona [~seaona@93.176.135.96] has quit [Ping timeout: 256 seconds] 00:15 -!- seaona [~seaona@93.176.135.96] has joined #bitcoin-core-pr-reviews 01:21 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 01:25 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 260 seconds] 01:39 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 01:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 260 seconds] 02:04 -!- kexkey [~kexkey@static-198-54-132-174.cust.tzulo.com] has quit [Ping timeout: 264 seconds] 02:58 -!- seaona [~seaona@93.176.135.96] has quit [Ping timeout: 256 seconds] 05:52 -!- kexkey [~kexkey@static-198-54-132-94.cust.tzulo.com] has joined #bitcoin-core-pr-reviews 06:31 -!- ekzyis [~ekzyis@ip-176-199-210-148.hsi06.unitymediagroup.de] has joined #bitcoin-core-pr-reviews 06:42 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 260 seconds] 07:25 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 07:26 -!- seaona [~seaona@93.176.135.96] has joined #bitcoin-core-pr-reviews 07:26 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews 07:29 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 264 seconds] 07:42 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 07:47 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 07:51 < MarcoFalke> We'll get started in 1 hour and 10 minutes. I am your host today :) 07:51 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has joined #bitcoin-core-pr-reviews 07:51 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has joined #bitcoin-core-pr-reviews 07:51 -!- Murch[m] [~murchmatr@2001:470:69fc:105::2aa8] has joined #bitcoin-core-pr-reviews 07:51 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #bitcoin-core-pr-reviews 07:51 -!- jomat [~jomat@2001:470:69fc:105::21] has joined #bitcoin-core-pr-reviews 07:59 -!- ekzyis [~ekzyis@ip-176-199-210-148.hsi06.unitymediagroup.de] has quit [Quit: Connection closed] 08:01 -!- ekzyis [~ekzyis@ip-176-199-210-148.hsi06.unitymediagroup.de] has joined #bitcoin-core-pr-reviews 08:16 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 08:17 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has left #bitcoin-core-pr-reviews [] 08:17 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 08:32 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has quit [Quit: Ping timeout (120 seconds)] 08:43 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-pr-reviews 08:44 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews 08:54 -!- oliver-offing [~oliver@189.1.174.14] has joined #bitcoin-core-pr-reviews 08:57 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 09:00 < MarcoFalke> Welcome to the review club today! 09:00 < stickies-v> Hi everyone! 09:00 < svav> Hi 09:00 < emzy> Hi 09:00 < oliver-offing> Hi all, first time here. Excited! 09:00 < seaona> hi! 09:01 < MarcoFalke> Welcome oliver-offing and every else here for the first time. 09:01 < raj_> Hello.. 09:01 -!- Azor [~Azor@190-36-240-30.dyn.dsl.cantv.net] has joined #bitcoin-core-pr-reviews 09:01 < ekzyis> hi :) 09:01 < Azor> Hi everyone 09:01 < MarcoFalke> Ok, let's get started. Did you review the PR? y/n? 09:01 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:01 < raj_> y 09:01 < ekzyis> y 09:02 < emzy> n 09:02 < seaona> y 09:02 < stickies-v> y 09:02 < oliver-offing> n 09:02 < svav> n 09:02 < MarcoFalke> nice, seeing quite a few yes 09:02 -!- lsilva_ [sid489830@helmsley.irccloud.com] has quit [Ping timeout: 245 seconds] 09:03 < MarcoFalke> So let's jump right into the first question :) 09:03 < MarcoFalke> Which places use the status of the Taproot deployment? Which of those are policy related? Hint: Search for Consensus::DEPLOYMENT_TAPROOT, for example with git grep 'Consensus::DEPLOYMENT_TAPROOT'. 09:03 < Kaizen_Kintsugi> Hi 09:04 < stickies-v> It was used for policy in MemPoolAccept::PreChecks. It is/was also used for what seems non-policy in GetBlockScriptFlags and ChainImpl::isTaprootActive. 09:04 < raj_> I think there are two places where its used. Once for script flag calculation, and other for input standardness test? 09:04 -!- lsilva_ [sid489830@id-489830.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews 09:04 < MarcoFalke> raj_: Correct, though there was one more (isTaprootActive) 09:04 < raj_> Ah right.. 09:04 < seaona> check input standards 09:05 < MarcoFalke> stickies-v: Correct. Anyone knows what isTaprootActive is used for? 09:05 < stickies-v> it was used by the rpc client, I believe for getblockchaininfo? 09:05 < raj_> Its used to determine weather taproot activation is reached given a specific block height? 09:06 < MarcoFalke> Oh, I meant which part of the codebase is using it :) 09:06 < MarcoFalke> (The caller) 09:06 < stickies-v> hmm no sorry not for getblockchainactive, just to check if the wallet could import taproot descriptors already 09:06 < MarcoFalke> stickies-v: getblockchaininfo is also using it, so you are still right 09:07 < Kaizen_Kintsugi> it looks like chain interfaces? 09:07 < MarcoFalke> Kaizen_Kintsugi: Yes, isTaprootActive is part of the chain interface 09:07 < MarcoFalke> The chain interface is there for multiprocess and usually called by the wallet or GUI 09:08 < MarcoFalke> In this case it is called by a wallet RPC 09:08 < MarcoFalke> So to summarize the 4 places I found: GetBlockScriptFlags (consensus-related), AreInputsStandard (mempool policy), getblockchaininfo (RPC), isTaprootActive (wallet RPC) 09:08 < MarcoFalke> Which function was responsible to check if a transaction has a Taproot input? Hint: Start looking in MemPoolAccept::PreChecks. 09:09 < raj_> It was the now modified AreInputStandard function.. 09:09 < seaona> bool AreInputsStandard(const CTransaction& tx, const CCoinsViewCache& mapInputs, bool taproot_active) 09:09 < stickies-v> `Solver` parses the script type, `AreInputsStandard` checks the output of Solver to check if it was a taproot script 09:09 < MarcoFalke> raj_: seaona: Correct 09:09 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 09:09 < MarcoFalke> stickies-v: Correct 09:10 < MarcoFalke> How does the pull request change the function? Is the return value or the function signature changed? 09:10 -!- oliver44 [~oliver@189.1.174.14] has joined #bitcoin-core-pr-reviews 09:10 -!- opcode_ [~opcode_@188.25.162.201] has joined #bitcoin-core-pr-reviews 09:10 < ekzyis> it removes the flag if taproot is active, since now it is always active 09:11 -!- pinheadmz_ [~pinheadmz@hns-contributor.dev] has joined #bitcoin-core-pr-reviews 09:11 < stickies-v> The function signature is changed because the last argument `taproot_active` is removed. The return type is unchanged. The function does not check anymore if taproot has been activated. As long as the longest chain has a taproot activation block height of 709,632, there should be no behaviour change. 09:11 < seaona> it won't return false on the assert: 09:11 < seaona> if (!taproot_active) return false; 09:11 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:11 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:11 < seaona> as it's removed. Also the function argument for checking input standards 09:12 < MarcoFalke> For anyone following, we are currently looking at https://github.com/bitcoin/bitcoin/blob/38b2a0a3f933fef167274851acaad0fd9104302a/src/validation.cpp#L727 and https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/policy/policy.h#L111 + policy.cpp 09:12 -!- fjahr [sid374480@uxbridge.irccloud.com] has quit [Ping timeout: 245 seconds] 09:13 < raj_> quick question: in testnet the taproot activation height is 0. https://github.com/bitcoin/bitcoin/blob/64059b78f59e45cc4200ca76d0af8c6dff8a20d4/src/chainparams.cpp#L211 09:13 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews 09:14 < raj_> What does that mean? Its always active in testnet? 09:14 < MarcoFalke> seaona: Correct. stickies-v: I'd say the function itself does change behavior. We'll get into the behavior changes a bit later. 09:14 < MarcoFalke> raj_: Yes, taproot is always active in regtest and signet 09:14 < raj_> Ok.. thanks.. 09:16 < MarcoFalke> So to summarize the behavior change of the function: Previously AreInputsStandard returned false when it encountered a taproot spend, now it returns true if all inputs are otherwise standard. 09:16 < MarcoFalke> Does this pull request change the handling of consensus-invalid transactions? 09:16 -!- Netsplit *.net <-> *.split quits: dergoegge, pinheadmz, oliver-offing, FelixWeis, notmandatory_, lightlike 09:16 < raj_> I think it doesn't. The PR only affects policy changes.. 09:17 < oliver44> No, only changes transaction relay policy 09:17 < MarcoFalke> raj_: Yes. It only changes tx relay (and wallet behavior) 09:17 < stickies-v> MarcoFalke : it would only return false if taproot was not actually activated yet, right? I.e. the current master branch would still return true at this point in time when there are taproot inputs? 09:17 < seaona> I am not sure about this one. As far as I see,  the taproot_active bool is removed from the args, nothing else affecting? 09:18 < stickies-v> and agreed, this PR doesn't seem to affect any consensus behaviour 09:18 < MarcoFalke> stickies-v: Good question! The function in current master may return false if taproot_active was set to false. 09:19 < MarcoFalke> Can anyone explain why taproot_active might be set to false? 09:19 < svav> If a node has not been upgraded? 09:19 < ekzyis> if someone has not upgraded his node yet? 09:20 < MarcoFalke> Let's assume we are running the current master branch. 09:20 < seaona> basically if the deployment is not performed? 09:20 < seaona>  DeploymentActiveAfter(m_active_chainstate.m_chain.Tip(), args.m_chainparams.GetConsensus(), Consensus::DEPLOYMENT_TAPROOT); 09:20 < raj_> MarcoFalke, for unupdated nodes, and when activation height is not reached for updated nodes.. 09:20 < MarcoFalke> seaona: Yes. At what time would this happen in normal operation? 09:20 < stickies-v> ah or when the node hasn't synced to current chaintip? 09:21 < raj_> initial block download.. 09:21 < MarcoFalke> yes, during IBD (initial block download) the node syncs the chain and might not be on the current tip 09:21 < seaona> aha I see 09:21 < stickies-v> right, so that explains the behaviour change I didn't catch earlier 09:22 < ekzyis> interesting, was already useful to be here. (also first timer here) 09:22 < MarcoFalke> stickies-v: Was good to have your question to clarify it. 09:22 -!- lightlike [sid521075@id-521075.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews 09:22 -!- Netsplit over, joins: FelixWeis, notmandatory_, dergoegge 09:23 < raj_> probably a stupid question, why do we disable spending before activation? but don't disable utxo creation.. 09:23 -!- oliver44 is now known as OliverOffing 09:23 < MarcoFalke> raj_: Good question. This is also the next question. 09:23 < MarcoFalke> Are there any (theoretical) issues with the change? If yes, give examples of adverse effects. Hint: Is the Taproot activation set in stone? What happens if a wallet creates a transaction with Taproot inputs before Taproot is active? 09:23 -!- lightlike is now known as Guest3086 09:24 < ekzyis> the transaction is not relayed? 09:24 < stickies-v> Taproot outputs that predate taproot activation height can be spent by anyone. In case of a huge reorg (going back to before block 709,632) to a chain that has no or a later taproot activation block, taproot outputs can be stolen. 09:25 < raj_> If a non majority hashrate is only updated at that time, can that cause chain split? 09:25 < OliverOffing> Taproot activation is hardcoded at a blockheight, so theoretically a 51% attack could rewrite history back to before Taproot was activated 09:26 < MarcoFalke> ekzyis: Yes, you are on the right path. (The full answer is a bit tricky, though) 09:26 < ekzyis> okay, looking at the other answers, I thought my answer was way too simple :D 09:27 < ekzyis> but aren't they also correct? 09:27 < MarcoFalke> stickies-v: correct. Though, sending to taproot *outputs* is always standard (This was changed in a previous release) 09:27 < MarcoFalke> raj_: I think there is no risk of a chain split with just this change 09:29 < raj_> MarcoFalke, yup right.. 09:29 < MarcoFalke> OliverOffing: Currently the taproot activation is not (yet) hardcoded at a blockheight. While it has a minimum activatio height, the status is determined by version bits signalling in the chain. 09:29 < raj_> Maybe another thing is, before activation a taproot utxo can be spent by anyone if majority hashrate haven't updated yet? 09:30 < MarcoFalke> raj_: Right, but this is the case on current master already. 09:31 < raj_> Yup.. but I can't just claim a taproot utxo out there with invalid sig because no miner would mine it, and most of the nodes are updated right now.. 09:32 < MarcoFalke> for reference, it was made standard in https://github.com/bitcoin/bitcoin/pull/15846 09:33 < michaelfolkson> [17:14:02] What does that mean? Its always active in testnet? (sorry to skip back, I arrived late) 09:33 < michaelfolkson> Has this change in this PR already been applied to testnet then? 09:34 < MarcoFalke> raj_: On a chain without taproot active (that is, without taproot rules being enforced), you *can* steal taproot utxo 09:34 < MarcoFalke> Only as a miner, though 09:34 < raj_> michaelfolkson, I think taproot spending was always standard in testnet, and there was no policy rule.. 09:35 < MarcoFalke> michaelfolkson: The discussed pr changes only relay policy and wallet RPC logic, not the activation status of a deployment. 09:35 < MarcoFalke> michaelfolkson: taproot is always active on regtest and signet 09:35 < MarcoFalke> On main and testnet3 it was deployed by version bits signalling 09:35 < michaelfolkson> But not always active on testnet right? 09:35 < michaelfolkson> Gotcha, thanks 09:36 < raj_> MarcoFalke, hmm makes sense.. So is the reasoning for "disabling spend until activation" is like, we wanna make sure a taproot witness should only appear on chain when large majority of the network already knows how to deal with it? 09:36 < Kaizen_Kintsugi> ah I get it now 09:37 < stickies-v> raj_ I think you don't need majority of network, just majority of miners 09:38 < raj_> stickies-v, yes thats correct.. 09:40 < michaelfolkson> Sorry, confused. You talking about policy here or disabling ability to spend in the Core wallet? 09:41 < michaelfolkson> Oh you're talking about the wallet 09:42 < raj_> michaelfolkson, I think its about policy. I am not sure, but if a wallet did create a taproot spend before activation, it won't be propagated in the network.. 09:42 < raj_> Thats what this PR changes.. 09:43 < MarcoFalke> raj_: Good q. In theory it should be possible to include spends *before* activation (with or without witness), that is "invalid" or "valid". Though, obviously this is not safe (in the same way that sending to a taproot address is not safe in the first place). Though, it would be really messy relay-wise (as everyones mempool or just txs looked different). 09:45 < MarcoFalke> Also, it wouldn't be a safe soft fork deployment if miners would generally include spends that they can't validate 09:48 < MarcoFalke> So to summarize the answer of negative effects if this patch was run with taproot being active: (1) One issue is that the wallet now allows import of taproot descriptors at any time. If someone were to send to those descriptors without taproot being active on the chain, miners could claim the outputs. 09:49 < michaelfolkson> Just for clarity, this PR only makes changes for when you are still syncing the chain (IBD). In the run up to activation the wallet did allow you to send to a Taproot address but policy didn't relay that transaction https://bitcoin.stackexchange.com/questions/107186/should-the-bitcoin-core-wallet-or-any-wallet-prevent-users-from-sending-funds 09:49 < michaelfolkson> Maybe that is obvious to people 09:49 < MarcoFalke> Obviously sending to future (unenforced) witness programs is an issue already, but exposing it through the wallet is an actual concern for us. 09:50 < Kaizen_Kintsugi> good to know 09:50 < Kaizen_Kintsugi> damn these are good learning xps 09:50 < MarcoFalke> (2) Another issue is that txs with taproot inputs (sent by the wallet, RPC or over P2P) while *segwit* is inactive would fill the mempool without being mined. 09:50 < MarcoFalke> <- on this one I am not 100% sure (haven't tested it, but I read the code) 09:50 < Kaizen_Kintsugi> that sounds like it could be expoited as an attack? 09:51 < MarcoFalke> Kaizen_Kintsugi: Can you clarify? 09:51 < MarcoFalke> Also, let's jump into the next q: Is it theoretically possible for a mainnet chain to exist that has Taproot not activated or activated at a different block height? 09:51 < Kaizen_Kintsugi> COuld someone spam txs with tr inputs to fill up a mempool? 09:52 < MarcoFalke> To clarify, I mean a *valid* mainnet chain 09:52 < Kaizen_Kintsugi> MarcoFalke: I guess no, tr activation is controled by blockheight and version bits? 09:52 < MarcoFalke> Kaizen_Kintsugi: Yes, those txs will fill up your mempool and the mempool of nodes that run this patch. 09:53 < raj_> I would incline towards no.. That seems like a chain split recipe. All the nodes should agree on when a taproot block is valid? 09:53 < MarcoFalke> Hint: Think about large reorgs 09:53 < seaona> I am not sure. Why couldn't it be at a different block height? 09:54 < stickies-v> yes I it's theoretically possible, if we reorg back long enough so that we don't have enough taproot signaling blocks to activate speedy trial? 09:54 < seaona> it's not hardcoded 09:54 < michaelfolkson> All nodes should agree on when Taproot rules are being enforced 09:54 < MarcoFalke> seaona: stickies-v: Correct. It could both be at a *different* block (a later block) or happen *not at all*. 09:55 < stickies-v> the minimum activation height is hardcoded in core, but that could also easily be changed with a forked version of Core? 09:55 < MarcoFalke> Which "property "would the chain need to have to be considered valid? 09:55 < MarcoFalke> stickies-v: Yes, it could be changed, but that wouldn't be safe at all and also violate the BIP (thus be invalid) 09:56 < MarcoFalke> I am only asking about valid chains 09:56 < stickies-v> ah, then how could the activation height be different in practice? 09:58 < MarcoFalke> stickies-v: It could be at a later point in time if miners went back and mined a different chain where they started signalling later 09:58 -!- RandyMcMillan [~RandyMcMi@47.205.11.3] has joined #bitcoin-core-pr-reviews 09:58 < michaelfolkson> They would need to start mining on a block months deep though so in reality not viable 09:59 < MarcoFalke> So they mine enough blocks to be *above* the minimum activation height and *below* the vb timeout 09:59 < raj_> MarcoFalke, in that case they could also go back a not signal at all right? Like segwit? :D 09:59 < MarcoFalke> Ok last question: Does this change affect miners running this code? Assume that the miner is running on a chain that has Taproot not active. Would the miner attempt to include the transaction in a block? Hint: Look at CreateNewBlock. 09:59 < stickies-v> ah I thought timeout was before min activation height for speedy trial, thanks for clearing that up 10:00 < michaelfolkson> If there is a months long re-org that is almost an Armageddon scenario 10:00 < MarcoFalke> stickies-v: timeout is given in "time" and min height is given in block height. While the two are expected to not overlap, with massive amounts of POW, I think they can be made to overlap 10:01 < MarcoFalke> To answer the last question: I think the miner would include the spend, unless segwit was not active. 10:02 < sipa> let's call the amount of pow that requires "1 powwow" 10:02 < MarcoFalke> Let's wrap up the meeting 10:02 -!- Guest3086 [sid521075@id-521075.hampstead.irccloud.com] has quit [] 10:02 < MarcoFalke> #endmeeting 10:02 < raj_> MarcoFalke, it seems it doesn't affect.. We only check for segwit deployment. So as taproot is already part of segwit schemes so its already covered? 10:02 -!- Guest3086 [sid521075@id-521075.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews 10:02 -!- Guest3086 is now known as Lightlike 10:02 < stickies-v> sipa ACK 10:03 -!- Lightlike is now known as Guest9388 10:03 < Kaizen_Kintsugi> Thanks for hosting. Learned a lot today 10:03 < raj_> MarcoFalke, thanks for hosting.. great meeting.. 10:03 < MarcoFalke> raj_: Yes, that is what I read from the mining code. The miner is happy to include taproot spends as soon as segwit (v0) is active. 10:03 < seaona> thank you!! Very interesting meeting 10:03 < svav> Thanks 10:03 < dariusparvin> Thanks MarcoFalke! 10:03 < stickies-v> thanks a lot MarcoFalke for hosting and everyone for the discussion! 10:03 < MarcoFalke> Thanks for everyone who attended. Great answers and discussions! 10:04 < OliverOffing> Yeah thanks MarcoFalke and all. Learned a lot! 10:04 < ekzyis> yes, thank you very much! 10:04 < michaelfolkson> Thanks MarcoFalke! 10:06 -!- Guest9388 is now known as lightlike 10:06 -!- lightlike [sid521075@id-521075.hampstead.irccloud.com] has quit [Changing host] 10:06 -!- lightlike [sid521075@user/lightlike] has joined #bitcoin-core-pr-reviews 10:08 -!- seaona [~seaona@93.176.135.96] has quit [Ping timeout: 256 seconds] 10:08 -!- ekzyis [~ekzyis@ip-176-199-210-148.hsi06.unitymediagroup.de] has quit [Quit: Connection closed] 10:08 < OliverOffing> See you all next week 10:09 -!- OliverOffing [~oliver@189.1.174.14] has quit [Quit: OliverOffing] 10:10 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 10:10 -!- Azor [~Azor@190-36-240-30.dyn.dsl.cantv.net] has quit [Quit: Connection closed] 10:21 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews 10:25 -!- dariusparvin [~dariuspar@c-24-130-243-152.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 10:27 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 10:29 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 10:40 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 245 seconds] 10:49 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 10:50 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 10:53 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 245 seconds] 10:57 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds] 11:06 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed] 11:17 -!- opcode_ [~opcode_@188.25.162.201] has quit [Quit: Connection closed] 11:28 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 11:30 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 11:30 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit] 11:31 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 11:33 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 11:37 -!- RandyMcMillan [~RandyMcMi@47.205.11.3] has quit [Quit: Connection closed] 11:37 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds] 11:40 -!- kexkey [~kexkey@static-198-54-132-94.cust.tzulo.com] has quit [Quit: Textual IRC Client: www.textualapp.com] 11:48 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 11:52 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 245 seconds] 11:58 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 240 seconds] 12:03 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 12:07 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds] 12:08 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:21 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 12:26 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 12:39 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 12:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 245 seconds] 12:45 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews 12:56 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 13:00 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds] 13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 260 seconds] 14:50 -!- jeremyrubin [~jeremyrub@ec2-44-199-24-18.compute-1.amazonaws.com] has quit [Quit: The Lounge - https://thelounge.chat] 14:50 -!- jeremyrubin [~jeremyrub@ec2-44-199-24-18.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews 15:49 -!- Common [~Common@user/common] has quit [Quit: Leaving] 15:51 -!- Common [~Common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews 15:52 -!- Common [~Common@096-033-221-075.res.spectrum.com] has quit [Changing host] 15:52 -!- Common [~Common@user/common] has joined #bitcoin-core-pr-reviews 16:17 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews 16:18 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 268 seconds] 16:19 -!- lukedashjr is now known as luke-jr 16:29 -!- ajonas_ [uid385278@id-385278.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews 17:31 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 17:32 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews 18:43 -!- virtu [~virtu@p5b15b053.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 18:45 -!- virtu [~virtu@p5b15b173.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 18:56 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 19:01 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds] 19:03 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 19:05 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews 19:07 -!- ajonas_ [uid385278@id-385278.helmsley.irccloud.com] has quit [Quit: Connection closed for inactivity] 19:37 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 19:42 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 245 seconds] 19:56 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 20:01 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 260 seconds] 20:05 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 20:06 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection] 22:05 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 23:20 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 23:25 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 260 seconds] 23:38 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews 23:42 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 260 seconds] --- Log closed Thu Nov 25 00:00:42 2021