--- Log opened Tue Feb 23 00:00:37 2021 00:25 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 240 seconds] 00:26 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 00:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 00:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 01:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 01:26 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection] 01:28 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation 01:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 01:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 02:02 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 02:02 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 02:07 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 240 seconds] 02:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds] 02:34 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds] 02:39 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##taproot-activation 03:15 <@michaelfolkson> I think the most complicated thing about the PR is handling naturally occurring re-orgs between the state transitions. Say you think you've moved to LOCKED_IN but then there is a natural re-org and you end up back in STARTED. I haven't looked into how this handled yet 03:17 <@michaelfolkson> Maybe this isn't as hard as I was thinking 03:18 <@michaelfolkson> A naturally occurring re-org happening at the same time as a chain split wouldn't be too pretty 03:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 03:27 < aj> you could reorg from blocks X Y Z A B C, where X, Y, Z are state STARTED and Z is a signalling block that just hits threshold at the last moment, leading A,B,C to be LOCKED_IN; to blockx X Y W D E F where W doesn't signal, so D E F are all still in state STARTED (or conceivably MUST_SIGNAL or FAILED). all that should work fine 03:30 < aj> note the versionbits code associates a state with a block/deployment, so you're finding State{A,taproot} = LOCKED_IN, and State{D,taproot} = STARTED, which remain true whether you reorg A out of your best chain or not 04:38 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 04:38 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation 04:50 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 04:54 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 05:04 -!- belcher_ is now known as belcher 05:14 < devrandom> really good analysis by Jeremy here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018469.html 05:17 < devrandom> IMO 05:38 -!- jonatack [~jon@37.172.15.119] has joined ##taproot-activation 05:38 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation 05:40 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Remote host closed the connection] 05:57 <@michaelfolkson> devrandom: Right, I think the analysis is entirely on whether to choose LOT=true or LOT=false (in the context of the PR code review later). TL;DR Jeremy would prefer LOT=true but not NACKing LOT=false 06:01 <@michaelfolkson> "I think devs wish it didn't exist because it is clear LOT=true *creates* the issues here" I agree, some would, but this wish is futile. There will be a UASF crowd regardless. And that crowd will grow as the delay of miner activation builds 06:27 -!- realname192 [~real@37.160.35.244] has joined ##taproot-activation 06:30 -!- realname192 [~real@37.160.35.244] has quit [Client Quit] 06:30 -!- realnam193 [~real@37.160.35.244] has joined ##taproot-activation 06:41 -!- realname194 [~real@37.160.35.244] has joined ##taproot-activation 06:45 -!- realnam193 [~real@37.160.35.244] has quit [Ping timeout: 265 seconds] 06:59 -!- jonatack [~jon@37.172.15.119] has quit [Quit: jonatack] 07:17 < aj> hey, aj, great job not being up at 1am 07:18 -!- jonatack [~jon@37.172.15.119] has joined ##taproot-activation 07:28 -!- realname194 [~real@37.160.35.244] has quit [Remote host closed the connection] 07:54 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation 08:05 -!- CARO3 [~Cesar@2804:7f4:c19d:f7fa:7c3a:c9c7:c1a3:9e77] has joined ##taproot-activation 08:05 -!- CARO1 [~Cesar@2804:7f4:c19d:f7fa:7c3a:c9c7:c1a3:9e77] has quit [Ping timeout: 240 seconds] 08:10 <@michaelfolkson> This is good from aj and Matt on there not being P2P banning between two nodes, one running LOT=true and one running LOT=false https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018464.html 08:13 <@michaelfolkson> I would've thought there would have been some P2P complexity given a LOT=true node is essentially receiving an invalid block (no miner signalling) from a LOT=false node during the MUST_SIGNAL phase but it appears not 08:15 <@michaelfolkson> The LOT=false node does appear to "recover" from this scenario by re-orging to the longest chain even when LOT=true ends up winning. 08:16 <@michaelfolkson> The LOT=true doesn't recover if LOT=false ends up winning. It gets forked off. That is my understanding, could be wrong... 08:17 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 08:17 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 08:18 < nothingmuch> michaelfolkson: is the last statement referring to 08:18 < nothingmuch> > If a lockinontimeout=true node is requesting compact blocks from a 08:18 < nothingmuch> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase, 08:18 < nothingmuch> I think that could result in a ban. 08:18 <@michaelfolkson> If what I said is correct the LOT=true node is taking more risk than the LOT=false node (assuming both nodes don't need to make transactions during the MUST_SIGNAL phase) 08:19 <@michaelfolkson> nothingmuch: Isn't that the scenario in the mailing list post I linked to? 08:19 < nothingmuch> yes, that's a quote 08:19 < nothingmuch> i screwed up the blockquoting didn't realize i was pasting multiple lines 08:20 <@michaelfolkson> Gotcha, yeah thanks 08:20 < nothingmuch> i wasn't sure if you were referring to that or if you meant after timeout 08:20 <@michaelfolkson> I think I just misread 08:21 <@michaelfolkson> "could result in a ban" Would be good to confirm then either way 08:21 <@michaelfolkson> And if that is optimal P2P behavior or not 08:21 < nothingmuch> FWIW i'm still trying to understand the logic behind that statement, i suppose i need to read the banning code 08:23 <@michaelfolkson> I'm assuming this kind of stuff wasn't discussed with the UASF of 2017 because of the rushed timetable but maybe there is a Shaolin Fry quote somewhere 08:25 <@michaelfolkson> It is interesting that from a network perspective competing lot=true and lot=false are as dangerous as each other (symmetry) 08:25 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 08:26 <@michaelfolkson> But from a single node perspective running lot=false is more risky than lot=true (in the case of the single node making the wrong choice against the ultimate consensus) 08:26 <@michaelfolkson> Sorry wrong way round. D'oh 08:26 <@michaelfolkson> Correction 08:27 <@michaelfolkson> But from a single node perspective running lot=true is more risky than lot=false (in the case of the single node making the wrong choice against the ultimate consensus) 08:28 <@michaelfolkson> If you go with lot=true and you end up being on the losing side you need an upgrade. If you go with lot=false and you end up being on the losing side you just re-org to the longest chain with all the forced signaling 08:51 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 08:52 <@michaelfolkson> CI failure on the functional tests. Also fails locally though not sure if it is for same reason yet 08:53 <@michaelfolkson> *functional test (singular) 08:54 <@michaelfolkson> I'm getting this "AssertionError: [node 3] Expected messages "['bad-vbit-unset-testdummy']" does not partially match log:" 08:58 <@michaelfolkson> Different tests. The CI is failing on feature_backwards_compatibility.py --descriptors. I'm failing on feature_bip8.py 09:19 < luke-jr> michaelfolkson: very oversimplified :P the LOT=false nodes that lose, also end up losing bitcoins, not simply a reorg 09:20 < luke-jr> michaelfolkson: can you tell what version that failure is testing against? 09:20 < luke-jr> feature_backwards_compatibility isn't very easy to get workign :/ 09:21 <@michaelfolkson> I haven't run it locally. Still trying to figure out what is wrong with feature_bip8.py 09:21 <@michaelfolkson> But I can 09:22 < luke-jr> oh, that's on Cirrus 09:23 < luke-jr> focus on your local failure, I'll dig into this one 09:23 <@michaelfolkson> Ok 09:23 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 09:23 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 09:57 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 10:03 <@michaelfolkson> We'll start the code review session on https://github.com/bitcoin/bitcoin/pull/19573 in a hour (19:00 UTC) 10:03 < stortz> discuss it on @tapoot-bip-review or just on github? 10:04 < stortz> ##taproot-bip-review* 10:04 <@michaelfolkson> Are you asking about the ##taproot-bip-review channel or whether the Taproot BIP is in scope of code review? 10:04 <@michaelfolkson> Sorry, I'm not sure what your question is 10:05 < stortz> I read that wrong 10:05 <@michaelfolkson> The code review meeting will be here on this channel 10:06 <@michaelfolkson> We've got 2 hours until the P2P meeting starts but we (probably?) won't need all that 10:06 <@michaelfolkson> darosior is showing, we'll wait and see if aj has managed to get enough sleep to attend 10:08 < darosior> Unfortunately still couldn't give a decent look to the PR, hopefully i have time before we start 10:21 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed] 10:22 -!- satosaurian [b0c7d357@ip-176-199-211-87.hsi06.unitymediagroup.de] has joined ##taproot-activation 10:26 < luke-jr> michaelfolkson: I think the previous-releases test failure is an intermittant issue with the test unrelated to the PR 10:26 < luke-jr> having Cirrus re-run it to be sure 10:27 <@michaelfolkson> Ok cool 10:28 -!- pseudozach [40bba059@64.187.160.89] has joined ##taproot-activation 10:31 <@michaelfolkson> Is it failing on other PRs? Or just has in the past? 10:34 < luke-jr> not sure, but it fails randomly on the commit prior to the PR branch 10:40 -!- Talkless [~Talkless@mail.dargis.net] has joined ##taproot-activation 10:49 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation 10:50 -!- criley_49 [~criley@107.87.138.67] has joined ##taproot-activation 10:50 -!- criley_49 [~criley@107.87.138.67] has quit [Remote host closed the connection] 10:54 -!- lucasmoten [~lucasmote@64.64.117.33] has joined ##taproot-activation 10:54 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Ping timeout: 272 seconds] 11:00 -!- vanity [~vanity@195.181.160.175.adsl.inet-telecom.org] has joined ##taproot-activation 11:00 < vanity> hi 11:00 <@michaelfolkson> OK that's 7pm. Anyone here for the code review? 11:00 <@michaelfolkson> #startmeeting 11:00 -!- AnthonyRonning [0cee2182@12.238.33.130] has joined ##taproot-activation 11:00 <@michaelfolkson> Say hi if you are 11:00 < vanity> hi 11:00 < AnthonyRonning> hi 11:00 < luke-jr> hi 11:00 < belcher> hi 11:01 <@michaelfolkson> The PR link is here: https://github.com/bitcoin/bitcoin/pull/19573 11:01 < nickler> hi, I only had a very shallow look at the PR 11:01 <@michaelfolkson> Cool, no worries 11:01 <@michaelfolkson> Anybody else had a chance to look at the PR? 11:02 < luke-jr> michaelfolkson: btw https://github.com/bitcoin/bitcoin/issues/20270 11:02 < darosior> hi 11:02 <@michaelfolkson> luke-jr: Aha cool, so that explains that functional test failing 11:02 <@michaelfolkson> Anybody else looked at the PR? 11:02 < luke-jr> apparently it's a long-running bug in the test XD 11:03 < darosior> No homework for me neither.. 11:03 < lucasmoten> im looking over 19573 now 11:03 < AnthonyRonning> looking now 11:03 <@michaelfolkson> Ok no worries. So at a high level (and Luke can correct me) there was this BIP 9 logic sitting in the Core codebase and it was never used 11:04 < luke-jr> never used in the most recent releases anyway; obviously it was previously for Segwit ;) 11:04 <@michaelfolkson> Ok I did wonder that lol 11:04 < luke-jr> (so it's not like the code is untested) 11:04 <@michaelfolkson> Ok so this code was used to activate SegWit 11:04 < luke-jr> 0.20 or 0.21, we changed Segwit to use a fixed block height instead of BIP9 11:05 -!- criley_ [~criley@107.87.138.67] has joined ##taproot-activation 11:05 <@michaelfolkson> So it was tested for SegWit but not actually used for SegWit? Is that right? 11:05 < darosior> michaelfolkson: no, both 11:05 < luke-jr> it was used for Segwit and failed due to the miner problems 11:05 < luke-jr> the fixes in BIP148 were never merged into Core 11:06 <@michaelfolkson> Oh ok, gotcha. Just with the small change on the fixed block height 11:06 < luke-jr> so this is starting from the original BIP9 code 11:06 <@michaelfolkson> Ok 11:06 < luke-jr> no, fixed block height means 0.21 doesn't use this code anymore 11:06 < luke-jr> so as of right now it's effectively dead code 11:07 <@michaelfolkson> So high level, the code for validating Taproot transactions is already merged in Core. And you can use that on regtest and signet. But obviously we need to activate Taproot on mainnet and this is the code to do that 11:07 -!- criley_ [~criley@107.87.138.67] has quit [Remote host closed the connection] 11:07 < luke-jr> well, this is the code that replaces BIP 9 with BIP 8 11:07 < luke-jr> actual activation parameters are NOT included here 11:07 < luke-jr> so it remains dead code after this PR, until a later change to set params 11:08 <@michaelfolkson> The parameters are included. Just what they are set to is not finalized 11:08 -!- criley_ [~criley@107.87.138.67] has joined ##taproot-activation 11:08 <@michaelfolkson> And hence whatever they are set to currently is irrelevant 11:08 < luke-jr> no, the parameters are not included 11:08 <@michaelfolkson> (in the code) 11:09 <@michaelfolkson> Hmm... 11:09 < luke-jr> anyway, the start of this PR has some test refactoring by aj 11:09 < luke-jr> then the actual changes to make the BIP 9 code into BIP 8 11:10 <@michaelfolkson> Right shall we go through commit by commit unless anyone has questions at a high level? 11:10 < luke-jr> then more refactoring by aj 11:10 < luke-jr> then extra tests 11:10 <@michaelfolkson> The refactoring commits are pretty simple 11:10 < vanity> is aj here? 11:10 <@michaelfolkson> What does MTP stand for in that first commit? 11:11 <@michaelfolkson> I don't think aj is 11:11 < luke-jr> Median Time Past 11:11 <@michaelfolkson> Ah ok 11:11 < luke-jr> BIP 9 began phases based on the block timestamps 11:11 -!- criley_ [~criley@107.87.138.67] has quit [Remote host closed the connection] 11:11 < luke-jr> so parameters were start/timeout times, not heights 11:11 <@michaelfolkson> Commits are here: https://github.com/bitcoin/bitcoin/pull/19573/commits 11:11 < luke-jr> BIP 8 changes them to use well-defined heights 11:11 <@michaelfolkson> Top two are unit tests 11:12 -!- criley_ [~criley@107.87.138.67] has joined ##taproot-activation 11:12 -!- prayank [~Prayank@2409:4053:2d08:b361:ad7a:5d0c:7e74:e825] has joined ##taproot-activation 11:12 <@michaelfolkson> The commit we are looking at is: https://github.com/bitcoin/bitcoin/pull/19573/commits/52fcdb6b00b72cfb802d035496eb71813b20cc97 11:12 <@michaelfolkson> Presumably we can't rename BIP 9 to BIP 8 across the whole codebase :) 11:13 -!- criley_ [~criley@107.87.138.67] has quit [Remote host closed the connection] 11:13 < luke-jr> michaelfolkson: a later commit does that 11:13 <@michaelfolkson> Ok 11:14 < luke-jr> Note that the BIP 9 code used 2008 dates for things which were never or always active (eg, on test networks) 11:14 < luke-jr> since there is obviously no valid height for 2008 (pre-genesis), BIP 8 is changing those to use a constant (-2 internally) 11:14 <@michaelfolkson> Right, and we're substituting in NEVER_ACTIVE for those dates 11:14 < luke-jr> (and -1 for always-active) 11:16 <@michaelfolkson> Why is startheight set to 144 in rpc_blockchain.py? 11:16 <@michaelfolkson> At the bottom? 11:16 <@michaelfolkson> (functional test) 11:17 <@michaelfolkson> At the bottom of this commit I mean 11:17 -!- jay8 [c1207fee@193.32.127.238] has joined ##taproot-activation 11:17 < luke-jr> the period for the test chain is 144 blocks, so that's the first period it would have used in BIP 9 with starttime 0 11:17 < luke-jr> AIUI 11:18 < luke-jr> with BIP 8 we could probably make it use the very first period, but there's no reason to do so, and it would just add to the complexity of the changes 11:18 <@michaelfolkson> The period? Like difficulty adjustment period? 11:18 < luke-jr> not to mention in the real world, no start height would ever be 0 :p 11:18 < luke-jr> yes 11:18 < luke-jr> consensus.nMinerConfirmationWindow = 144; // Faster than normal for regtest (144 instead of 2016) 11:18 < luke-jr>  11:19 -!- jay8 is now known as jamesleopold 11:20 < AnthonyRonning> i'm still new in the codebase, but ack `52fcdb6` - looks good to me (was also wondering about 144 at first) 11:20 <@michaelfolkson> Hmm weird. Mining difficulty is set really really low on regtest right? So I don't know why it would need a different difficulty adjustment period but hey 11:20 * michaelfolkson shrugs 11:20 < luke-jr> michaelfolkson: for testing BIP 8 (formerly 9) ;) 11:21 <@michaelfolkson> Ok cool. Thanks AnthonyRonning. Yeah I think the commit is as an ACK from me too 11:21 < luke-jr> be sure to post final ACKs in the PR when we're all done ;) 11:21 <@michaelfolkson> Haha hopefully ACKing more than one commit 11:21 < prayank> L 1293 in src/rpc/blockchain.cpp 11:22 < prayank> What is the meaning of "bit gains its meaning" ? 11:22 -!- btc_iota [2f9d7da2@47.157.125.162] has joined ##taproot-activation 11:22 <@michaelfolkson> Can you post a link to the line prayank? Or I can 11:23 < darosior> prayank: when setting a bit starts having consequences 11:23 < luke-jr> prayank: prior to that height, the bit does not mean anything related to the deployment in question 11:23 < luke-jr> so setting it is meaningless (from our perspecitve0 11:24 < lucasmoten> so it comes into effect at startheight, and prior to that, the bit is ignored/irrelevant 11:24 < luke-jr> so for taproot, we'll be saying bit 2=taproot between blocks 693504 and 745920 - but outside those heights, bit 2 could mean anything 11:24 < luke-jr> right 11:25 < vanity> "bit's meaning is defined" might be a little more clear 11:25 < vanity> CMIIW 11:25 < prayank> michaelfolkson: https://github.com/bitcoin/bitcoin/blob/52fcdb6b00b72cfb802d035496eb71813b20cc97/src/rpc/blockchain.cpp#L1293 11:25 <@michaelfolkson> Thanks prayank 11:26 <@michaelfolkson> Some of the old code has a lockinontimeout and some of the old code doesn't. lockinontimeout was in BIP 9 11:27 <@michaelfolkson> For example it needs to be added to rpc_blockchain.py (again at the bottom) 11:27 <@michaelfolkson> Was the functional test not updated for BIP 9? 11:28 < luke-jr> lockinontimeout was not in BIP 9, and not in any of the old code 11:28 < prayank> darosior luke-jr lucasmoten Thanks. I wasn't sure reading that line what is gaining meaning. Sorry if its a dumb question. 11:29 <@michaelfolkson> I saw lockinontimeout in the old code somewhere, I'm sure... 11:29 < luke-jr> vanity: prayank: feel free to leave a "nit" comment on the line, in GitHub, but I'd rather leave it alone for this PR 11:29 < lucasmoten> not a dumb question. Always helps to clarify as phrasing for similar concepts and word spellings vary across cultures 11:30 <@michaelfolkson> But right the MUST SIGNAL phase was added 11:30 < darosior> michaelfolkson: maybe you were confused, it was not 11:30 < luke-jr> lucasmoten: I agree, but this is part of the existing code, not new ☺ 11:30 < darosior> michaelfolkson: you can still use git log -S to be convinced :p 11:30 <@michaelfolkson> Ha thanks darosior 11:30 < aj> #11818 was the pr that removed the old bip9 tests, i believe 11:31 <@michaelfolkson> It was in the old code of this commit https://github.com/bitcoin/bitcoin/pull/19573/commits/8a1817a08f16649c6a14e5f790c9dd81eec8f6d3 11:32 < darosior> michaelfolkson: it's just that the commit is modifying what a previous commit introduced 11:32 <@michaelfolkson> darosior: Oh right, gotcha thanks 11:32 <@michaelfolkson> OK so any other questions, thoughts on that commit? https://github.com/bitcoin/bitcoin/pull/19573/commits/23c38ba51661ee240ef80b52895ab2312e6f7fe6 11:33 <@michaelfolkson> Also ACK? 11:33 < darosior> (Maybe the root of confusion is that s/9/8/g was done *after* introducing the parameters for BIP8) 11:33 < luke-jr> michaelfolkson is tripping trying to get ahead of us on the review :P 11:33 <@michaelfolkson> I'm getting a little disorientated, that is true :) 11:34 < aj> luke-jr: "bit 2=taproot between blocks 693504 and 745920" -- the 2016 blocks after 745920 could be LOCKED_IN, in which case signalling via bit 2 could still mean taproot for those blocks 11:36 < luke-jr> aj: true 11:36 < luke-jr> good morning 11:38 <@michaelfolkson> Ok shall we move on? 11:38 < aj> luke-jr: good afternoon, i guess! 11:38 <@michaelfolkson> Lol 11:38 <@michaelfolkson> Evening here, my brain isn't on top form 11:39 * luke-jr suggests sticking to UGT, but OT 11:39 < aj> Good %GREETING_TIME% 11:40 < darosior> michaelfolkson: yep, let's move on i guess 11:40 <@michaelfolkson> OK next commit is enforcing the mandatory signaling during MUST_SIGNAL (this is only hit if lot is set to true) 11:40 <@michaelfolkson> https://github.com/bitcoin/bitcoin/pull/19573/commits/40fc1c5ff3ebef031b259a723b7064a00af053df 11:41 -!- rgrant [~rgrant@unaffiliated/rgrant] has joined ##taproot-activation 11:42 <@michaelfolkson> This was discussed a little earlier today I think but this has to deal with a re-org at the point it moves into the MUST_SIGNAL phase. You could go into it, re-org, be out of it and then enter it again 11:42 <@michaelfolkson> Potentially even multiple times (if multiple naturally reoccuring re-orgs) 11:43 <@michaelfolkson> This bool ContextualCheckBlockHeaderVolatile, I don't think is in reference to that 11:44 <@michaelfolkson> I'm not sure what this is handling to be honest 11:44 < luke-jr> michaelfolkson: eh? 11:44 <@michaelfolkson> What is a "volatile" block header? 11:45 < luke-jr> we check it a second time in ConnectBlock, in case LOT has changed since the header was accepted 11:46 <@michaelfolkson> In case LOT has changed in the software version we are running? 11:46 -!- AnthonyRonning [0cee2182@12.238.33.130] has quit [Quit: Connection closed] 11:47 < luke-jr> yes 11:47 < luke-jr> or we upgraded 11:48 < aj> that's only an upgrade in-between seeing the header and downloading the block; not an upgrade after we download the block, no? 11:49 <@michaelfolkson> So in theory we could flap between LOT=true and LOT=false and this would handle it? 11:49 <@michaelfolkson> I didn't think that would be handled 11:50 <@michaelfolkson> By flap I mean run LOT=true, change it to LOT=false, change it back to LOT=true etc 11:50 < prayank> LOT=true on Odd dates, LOT=false on Even dates :) 11:51 <@michaelfolkson> Ha 11:51 < aj> i think https://github.com/UASF/bitcoin/pull/22/files was the bip148 code to allow upgrades during/after the equivalent of MUST_SIGNAL 11:51 <@michaelfolkson> If that actually handles that I'm impressed 11:51 < luke-jr> aj: it would check during a reorg attempt too 11:52 < luke-jr> michaelfolkson: it would only handle false->true 11:52 < luke-jr> michaelfolkson: and only in some cases 11:52 <@michaelfolkson> Ok. So not recommended. You'd have to be pretty adventurous to try that with real money on the line 11:52 < luke-jr> if you're already on an anti-Taproot chain, you'd remain on it until a Taproot chain overtakes it 11:53 <@michaelfolkson> And some of the code from the UASF repo aj linked to is presumably reused here 11:54 <@michaelfolkson> I did wonder how much edge case testing you did on the UASF code given that it was rushed 11:54 <@michaelfolkson> (or at least that was my impression) 11:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 11:55 <@michaelfolkson> Oops did Luke not like that 11:55 <@michaelfolkson> OK who is still here? I'd like to get onto aj's functional test if we have time 11:55 < lucasmoten> the tests for this in the python look good 11:56 < darosior> I'm still here (reading through in parallel) 11:56 <@michaelfolkson> Right lucasmoten, I tried running it and got an error earlier but I'll try to work that out tomorrow 11:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 11:57 <@michaelfolkson> AssertionError: [node 3] Expected messages "['bad-vbit-unset-testdummy']" does not partially match log: 11:57 < nickler> Do the functional tests cover everything conceivable for such a test, or are there scenarios it doesn't cover? 11:57 <@michaelfolkson> Maybe we can end on the functional test if lucasmoten has looked at it 11:58 < aj> nickler: i don't think the functional tests directly cover the same node switching from lockinontimeout=false to true (or the converse i guess) 11:58 < aj> nickler: they're also a bit slow :-/ 11:58 < nickler> yeah I run them a couple of times seeing that they're quite probabilistic 11:59 < nickler> I guess the tests could cover lot-switching in principle 11:59 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation 11:59 <@michaelfolkson> Within a network of 4-5 nodes 12:00 -!- criley88 [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation 12:00 <@michaelfolkson> You'd need to do a custom Signet network to do at greater scale I'm guessing 12:00 < nickler> aj: do the tests also cover mixed network where lot=true has an earlier timeout? 12:00 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Client Quit] 12:00 < nickler> yeah, right the network partitioning aspects aren't covered either 12:01 < lucasmoten> michaelfolkson: do you get that assertion error every time you run? 12:01 < aj> nickler: no -- set_vbparams always has the same start/stop times between the lot=true/false nodes 12:01 < aj> setup_vbparams 12:02 <@michaelfolkson> lucasmoten: I haven't run it again, I was trying to work out what had failed 12:02 < luke-jr> lot-switching isn't really intended to be covered by this PR 12:03 <@michaelfolkson> The P2P consideration on a lot=true node potentially banning a lot=false node for sending "invalid" blocks isn't covered by the testing either 12:03 <@michaelfolkson> Though you said on the mailing list you weren't sure if it would do this aj (I think) and I haven't looked into the P2P banning code 12:04 < nickler> luke-jr: yeah that makes sense, the PR doesn't need to include lot-switching 12:05 <@michaelfolkson> OK well I'm going to play around more with the functional test tomorrow I think 12:06 <@michaelfolkson> Is there anything else people would like to discuss on the PR? 12:06 < darosior> luke-jr: why doesn't it intend to ? Since it's leaving the possibility to -say- use a new release with LOT=true on a datadir ran with LOT=false up until then, shouldn't it gracefully handle and test this ? 12:06 < aj> michaelfolkson: the functional test announces non-activating block headers to the lot=true node, and will error if it gets disconnected from the node, i believe; so it should be testing banning doesn't occur in simple cases. (sending the block rather than the header, and sending compact blocks might cause bans i think) 12:07 < luke-jr> darosior: softforks never have (aside from BIP148) - LOT is not special in this regard 12:08 < luke-jr> darosior: if there becomes a real need, a followup PR would be in order I suppose 12:08 < darosior> luke-jr: ok so the rationale is "handle that when/if we release a switch of LOT" ? 12:09 < luke-jr> darosior: it would need to be a scenario where there is actually a risk 12:09 < luke-jr> enforcing CSV is no different than enforcing LOT 12:10 < luke-jr> I mean, I could do a PR tomorrow if people want one.. but IMO it doesn't need to be part of this one 12:10 < darosior> I don't see a reason why it should either rn, just wanted to make it clear 12:10 < aj> luke-jr: switching directly from 0.21.0 to 0.21.x-lot-is-true but doing so during a MUST_SIGNAL period would want that code, i think 12:10 -!- criley88 [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Quit: Connection closed] 12:11 < aj> luke-jr: (ie, upgrading at the last minute, rather than when it was released) 12:11 < nickler> luke-jr: what about the peering spects matt is alluding to in the PR comment? 12:11 <@michaelfolkson> aj: If you are transacting during that time. Otherwise sit it out and you'll eventually re-org? 12:12 < luke-jr> aj: only if miners are creating an invalid chain 12:12 < luke-jr> aj: the same applies to every other softfork 12:12 < luke-jr> nickler: again, all these hypotheticals apply to any softfork, not specific to LOT. usually, there's no need 12:12 <@michaelfolkson> aj: You can sit out and wait for the re-org on lot=false even if it eventually loses 12:12 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:12 < aj> nickler: i think https://github.com/UASF/bitcoin/pull/24 is the corresponding code for bip148 fwiw 12:13 < aj> michaelfolkson: (well, if that's your attitude, why even run the node when you're not transacting?) 12:13 <@michaelfolkson> aj: Oh ignore me. You're talking about 0.21.0 which doesn't have lot=true or lot=false. 12:14 < aj> michaelfolkson: yeah 12:14 <@michaelfolkson> Sorry 12:14 <@michaelfolkson> I thought you meant switching from lot=false to lot=true 12:15 < luke-jr> nickler: note that there IS code already to detect if your peers are on another chain, and that would help too 12:15 < luke-jr> (specifically, your 8 outbound peers) 12:15 < darosior> I don't think anything is forward-incompatible, should we decide to go with LOT=true after LOT=false both the peering code and chainstate-switching code can be implemented at this point ? 12:16 < luke-jr> darosior: indeed; you only need the chainstate-switching code IF miners form an invalid chain and IF you're upgrading after that 12:16 < aj> chainstate-rewinding, not so much chainstate-switching i think? 12:16 < darosior> luke-jr: assuming you went with LOT=true ? 12:16 < luke-jr> darosior: either way 12:16 < luke-jr> darosior: LOT=true has nothing special here 12:16 < darosior> aj: yes 12:17 < darosior> luke-jr: "IF miners form an invalid chain" is only possible with LOT=true? 12:17 < luke-jr> I'm not sure peering code is actually needed at all 12:17 < luke-jr> darosior: no 12:17 < luke-jr> darosior: LOT=true strictly reduces the risks in that regard 12:17 < darosior> (in the context of the softfork obv) 12:17 < aj> darosior: "miners form an invalid chain" is possible with any soft-fork going from a release that doesn't know about the soft-fork to one that does 12:18 < luke-jr> it's also possible without a softfork (due to light wallets) 12:19 < aj> darosior: with MUST_SIGNAL miners could plausibly do it by accident though; provided miners don't mine non-standard transactions, they won't produce an invalid chain accoding to soft-fork rules even if they haven't upgraded. (though if someone else does, they might extend it) 12:20 < luke-jr> aj: the only time it's ever happened by accident, was with those same circumstances ;p 12:20 < darosior> right 12:20 < luke-jr> (or at least the most notable time) 12:20 < nickler> luke-jr: would you agree that peering code is needed if lot=false is the default? 12:20 < luke-jr> nickler: I'm not sure. It depends more on the network makeup. 12:20 < nickler> ok 12:22 <@michaelfolkson> I'm not sure what the network makeup has to do it. Assuming there are nodes with both lot=true and lot=false (say split half and half) is worst case 12:22 < luke-jr> so I kinda lost track of the conversation when my ISP cut out.. where are we at on the review? :x 12:22 < luke-jr> michaelfolkson: generally your node will try to keep 8 connections out to other nodes on the same block tip 12:22 < luke-jr> michaelfolkson: so long as 1/8 of the network has LOT=True, that shouldn't be a problem 12:23 < luke-jr> if it falls below that, some assistance might be desirable, but not necessarily *needed* 12:23 <@michaelfolkson> luke-jr: I think we did the non-test and non-refactor commits. The refactors seem pretty simple so I was going to play around with the functional test tomorrow 12:23 < luke-jr> no new ACKs :< 12:24 <@michaelfolkson> Ha. I'll chase people 12:24 <@michaelfolkson> Get them to at least ACK the commit(s) we looked at 12:24 < nickler> luke-jr: you could connect to LOT=true nodes on the same tip that are themselved partititioned 12:25 < nickler> would be interesting to simulate (I expect the probability is small) 12:25 < luke-jr> nickler: yes, but all the nodes will be constantly trying to satisfy their 8 peers; it's not much different than normal 12:25 < aj> luke-jr: that was strictder, which was making common tx's invalid? i'm not currently seeing if/when they were made non-standard first 12:26 < luke-jr> aj: ? 12:29 < luke-jr> aj: ? 12:29 <@michaelfolkson> I think we've lost him 12:30 < aj> aha, v0.8.0 introduced strictder as standardness i think 12:30 < aj> aj: the only time it's ever happened by accident, ... 12:30 -!- vanity [~vanity@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds] 12:31 < luke-jr> I don't recall the details 12:31 < aj> nickler: there's also the 2 blocks-only peers and the extra peer when you haven't seen a new block for a while and the extra blocks-only peer every now and then 12:32 < nickler> aj: right 12:34 -!- hsjoberg [~hsjoberg@c-0ec672d5.445-1-64736c11.bbcust.telenor.se] has joined ##taproot-activation 12:34 < nickler> either way there doesn't seem to be the need really for preferential peering in this PR 12:35 -!- rgrant [~rgrant@unaffiliated/rgrant] has left ##taproot-activation [] 12:36 < aj> i think it would make sense to have preferential peering in its own PR -- if there's no need to rush *something* in, better to look at in detail? 12:36 < darosior> Ok, i need to run, thanks everyone for the discussion 12:36 <@michaelfolkson> Thanks darosior 12:37 <@michaelfolkson> Would preferential peering have the downside that you could end up finding out that your lot choice wasn't consensus on the broader network and not finding out about longest chain? 12:38 <@michaelfolkson> If you are a lot=false node and all your peers are lot=false due to preferential peering you wouldn't find out that lot=true "won"? 12:39 < aj> trying to find lot=true outbounds doesn't prevent lot=false connecting to you as an inbound 12:40 < aj> (unless maybe if there's a _lot_ of end users running lot=true preferentially connecting to you and using up all your inbound slots, but that's a pretty good sign that you're on the right side of consensus) 12:40 < aj> (and easily fixed by firing up some lot=true nodes on amazon or similar, really) 12:42 <@michaelfolkson> There is a desire to do *something* in case a (highly unlikely) chain split happens but I'm not sure there is anything you can do in a software release to prepare for that 12:43 <@michaelfolkson> Or I haven't been convinced thus far... 12:44 <@michaelfolkson> Ok shall we wrap up then? P2P meeting is happening shortly for aj and anybody else 12:44 <@michaelfolkson> Thanks for attending, thanks for answering questions luke-jr aj 12:44 < prayank> michaelfolkson: P2P meeting? 12:45 <@michaelfolkson> Yeah #bitcoin-core-dev in 15 minutes. They have biweekly I think discussing Core P2P 12:45 < prayank> Okay. Thanks. 12:46 <@michaelfolkson> For anyone who is still here please add your reviews to the PR. You can ACK specific commits if you haven't looked at all of them. If you have looked at all of them you just ACK the top commit 12:47 <@michaelfolkson> Describe what you have done to assure yourself you are happy with the commit(s) ideally 12:47 < lucasmoten> I've looked it over enough to give an untested ACK. 12:48 < prayank> I added one comment with nit. Can't ACK without understanding everything or testing. Also not sure if anyone cares about my ACKs lol. 12:48 <@michaelfolkson> Great, thanks lucasmoten. If you continue to do reviewing of PRs (especially for new contributors, new reviewers) it is good to describe what you've done to assess that it is ACK worthy 12:49 <@michaelfolkson> If you can't ACK the code you can Concept ACK and/or Approach ACK if you are happy with the high level approach 12:49 < prayank> Sure 12:49 < aj> prayank: try to find a bug, if you succeed people will care; if you don't, it'll at least make your ack more valuable? 12:50 <@michaelfolkson> But again even with Concept ACK, Approach ACK try to give some context on what you've done to assess that. Just writing Concept ACK and nothing else isn't particularly helpful from new reviewers/contributors 12:51 <@michaelfolkson> And sure if you find a bug that definitely makes your review valuable ;) 12:51 < prayank> aj: :-D 12:51 <@michaelfolkson> #endmeeting 12:57 -!- jamesleopold [c1207fee@193.32.127.238] has quit [Quit: Connection closed] 12:59 -!- satosaurian [b0c7d357@ip-176-199-211-87.hsi06.unitymediagroup.de] has quit [Quit: Connection closed] 13:01 -!- fjahr [sid374480@gateway/web/irccloud.com/x-wtgxofjmyomzqblb] has quit [Ping timeout: 272 seconds] 13:03 -!- fjahr [sid374480@gateway/web/irccloud.com/x-piyhmzkmzjdkkqyq] has joined ##taproot-activation 13:08 -!- btc_iota [2f9d7da2@47.157.125.162] has quit [Quit: Connection closed] 13:11 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-lopkrozptkoybihj] has quit [Read error: Connection reset by peer] 13:11 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-wctqlxoztrxlnilq] has quit [Ping timeout: 272 seconds] 13:11 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-gkofmiznfvtcdhdl] has joined ##taproot-activation 13:12 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-iztdehhgiceanbhh] has quit [Ping timeout: 265 seconds] 13:12 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-dywaualargxrvjui] has joined ##taproot-activation 13:13 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-vcdpnxclfrimarst] has joined ##taproot-activation 13:39 -!- prayank [~Prayank@2409:4053:2d08:b361:ad7a:5d0c:7e74:e825] has left ##taproot-activation [] 13:55 -!- lucasmoten [~lucasmote@64.64.117.33] has quit [Quit: Leaving] 14:12 -!- hsjoberg [~hsjoberg@c-0ec672d5.445-1-64736c11.bbcust.telenor.se] has quit [Ping timeout: 272 seconds] 15:07 <@michaelfolkson> Why during the MUST_SIGNAL phase is the threshold applied? Doesn't it make sense to simply require that *all* (100 percent) blocks must signal rather than a threshold of blocks must signal? 15:15 < nickler> michaelfolkson: In a mixed network, the rules can become active, but in two separate chains because lot=true nodes will reject blocks from the lot=false chain which doesn't require 100% signalling. 15:22 < luke-jr> michaelfolkson: yeah, it's to ensure there will only ever be a single Taproot chain 15:22 < luke-jr> two Taproot chains would be pretty fail XD 15:25 < nothingmuch> c.f. bips/#1021 and discussion on 2021-02-02 16:11 <@michaelfolkson> Ok thanks 16:30 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Ping timeout: 240 seconds] 16:33 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined ##taproot-activation 16:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 16:39 -!- pseudozach [40bba059@64.187.160.89] has quit [Quit: Connection closed] 16:50 -!- jonatack_ [~jon@37.172.39.154] has joined ##taproot-activation 16:53 -!- jonatack [~jon@37.172.15.119] has quit [Ping timeout: 260 seconds] 18:15 -!- bluudix [~bluudz@103.108.94.45] has quit [Quit: Leaving] 18:28 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 18:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 18:57 -!- bluudz [~bluudz@103.108.94.45] has joined ##taproot-activation 19:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 19:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 19:03 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation 19:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 19:13 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 19:16 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 19:29 -!- jonatack_ [~jon@37.172.39.154] has quit [Ping timeout: 256 seconds] 19:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 20:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 22:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 22:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 22:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 23:07 -!- pox [~pox@141.226.243.49] has quit [Quit: pox] 23:09 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 23:20 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds] 23:30 -!- pox [~pox@141.226.243.49] has quit [Quit: pox] 23:32 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 23:34 -!- pox [~pox@141.226.243.49] has quit [Client Quit] 23:49 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation --- Log closed Wed Feb 24 00:00:38 2021