--- Log opened Wed Feb 08 00:00:39 2023
00:25 -!- djinni` [~djinni@static.38.6.217.95.clients.your-server.de] has quit [Quit: Leaving]
00:40 -!- djinni` [~djinni@static.38.6.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews
02:30 -!- b_101_ [~robert@185.242.5.35] has joined #bitcoin-core-pr-reviews
02:33 -!- b_101 [~robert@185.242.5.35] has quit [Ping timeout: 248 seconds]
02:49 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:918f:3bfb:c49e:30c0] has joined #bitcoin-core-pr-reviews
04:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4125:ef70:81ec:6465] has quit [Remote host closed the connection]
04:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4125:ef70:81ec:6465] has joined #bitcoin-core-pr-reviews
04:43 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:918f:3bfb:c49e:30c0] has quit [Ping timeout: 248 seconds]
04:53 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:918f:3bfb:c49e:30c0] has joined #bitcoin-core-pr-reviews
05:53 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:918f:3bfb:c49e:30c0] has quit [Ping timeout: 248 seconds]
06:05 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has joined #bitcoin-core-pr-reviews
07:11 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has quit [Ping timeout: 248 seconds]
07:22 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
07:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4125:ef70:81ec:6465] has quit [Remote host closed the connection]
07:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4125:ef70:81ec:6465] has joined #bitcoin-core-pr-reviews
07:53 -!- pablomartin [~pablomart@178-159-9-85.as42831.net] has joined #bitcoin-core-pr-reviews
08:06 -!- pablomartin_ [~pablomart@185.169.233.59] has joined #bitcoin-core-pr-reviews
08:06 -!- hernanmarino [~hernanmar@181.99.169.107] has joined #bitcoin-core-pr-reviews
08:06 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews
08:17 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
08:18 -!- theHeap [~theHeap@2602:ffb6:4:e396:f816:3eff:fe97:4975] has left #bitcoin-core-pr-reviews [Leaving]
08:18 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
08:19 -!- theHeap [~theHeap@2602:ffb6:4:e396:f816:3eff:fe97:4975] has joined #bitcoin-core-pr-reviews
08:47 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
08:50 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 255 seconds]
08:55 -!- kevkevin [~kevkevin@c-98-226-43-69.hsd1.il.comcast.net] has joined #bitcoin-core-pr-reviews
08:55 -!- dzxzg [~dzxzg@2600:387:f:6113::6] has joined #bitcoin-core-pr-reviews
08:56 < kevkevin> Hey guys
08:56 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
08:56 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has joined #bitcoin-core-pr-reviews
08:56 < kevkevin> only have gotten a chance to look at the stuff this morning so I'll mostly be listening in
08:57 -!- roze_paul [~quassel@132.216.191.43] has joined #bitcoin-core-pr-reviews
08:58 < _aj_> kevkevin: you've still got 2 minutes, plenty of time!
08:59 < glozow> enough time to sync signet
09:00 < _aj_> #startmeeting
09:00 < glozow> hi
09:00 < _aj_> aww, no bot
09:00 < pablomartin_> hello
09:00 < _aj_> hi all!
09:00 < svav> Hi
09:00 < codo> hi
09:00 < theStack> hi
09:00 < roze_paul> hi
09:00 < neha> hi
09:00 < kevkevin> hi
09:00 < michaelfolkson> hi
09:00 < _aj_> feel free to say hi everybody, just like classic dr nick. anybody's first time?
09:01 < lightlike> hi
09:01 < _aj_> today we're in a fork repo, https://bitcoincore.reviews/bitcoin-inquisition-16 -- bitcoin inquisition
09:01 < LarryRuane> hi
09:02 < _aj_> did anyone get a chance to look at the pr/repo/etc? y/n
09:02 < glozow> y
09:02 < codo> n
09:02 < lightlike> y (0.5)
09:02 < kevkevin> y (0.3)
09:02 < neha> n
09:02 < theStack> n
09:02 < svav> The notes yes
09:02 < roze_paul> y
09:02 < michaelfolkson> Also 0.5y
09:02 < pablomartin_> y
09:02 < LarryRuane> 0.2y
09:03 < dzxzg> n
09:03 < hernanmarino> Hi ! Only the notes and related links, i find it super interesting 
09:04 < _aj_> so, i guess "ask questions any time" is probably a given, but in case it's not - ask questions any time! going through the questions from the notes...
09:04 < _aj_> Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
09:05 -!- pablomartin [~pablomart@178-159-9-85.as42831.net] has quit [Ping timeout: 260 seconds]
09:05 < LarryRuane> concept ack, running the branch now, haven't really tested anything (not super clear on how to do that)
09:05 < michaelfolkson> Concept ACK, unsure on Approach ACK
09:06 < roze_paul> C-ack -> I find michaelfolkson's point [iiuc] on custom signets per softfork interesting. Played with the fork, but not the specific pr
09:06 < _aj_> well, the next question is concept-y, the one after is test-y
09:06 < _aj_> Why do we want to deploy consensus changes that aren’t merged into Bitcoin Core? What problems (if any) are there with merging the code into Bitcoin Core, and then testing it on signet afterwards?
09:07 < roze_paul> finding bugs in the consensus code is immeasurably better to do on signet than mainnet?
09:07 < roze_paul> and we want to test and build on top of them as well
09:07 < glozow> I imagine if we find a bug, fix it in Core, then later activate the soft fork, there could be a few unupgraded nodes enforcing a different set of rules
09:08 < LarryRuane> merging even unactivated consensus changes can break existing functionality as a side-effect
09:09 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:09 < _aj_> roze_paul: yep -- finding consensus bugs in mainnet is pretty painful, and can shut down your lightning nodes while you mess around with upgrading, eg
09:10 < _aj_> i guess another question is why do it on signet, rather than just on regtest?
09:10 < LarryRuane> glozow: +1 good point ... do we have to assume all nodes (or nearly all) are running actual releases? many of us run master branch, but not for long usually
09:11 < LarryRuane> maybe it isn't possible (or easy) to test LN on regtest?
09:11 < glozow> LarryRuane: well, if we add something to Core it would eventually go into a release
09:12 < lightlike> Also it's extremely hard to get consensus changes merged into core without overwhelming consensus, the threshold here is much lower
09:12 < _aj_> you can point multiple nodes at a signel regtest -- we do that ourselves in the functional tests; so i think LN testing is okay
09:12 < hernanmarino> _aj_ : is it because signet is a more "open" network ?
09:13 < michaelfolkson> glozow: Unless it was reversed (not that I'm recommending adding consensus changes to Core only to reverse them prior to a release)
09:13 < neha> regtest is pretty uniform -- on signet you might have different versions of code, different hardware, etc
09:13 < _aj_> hernanmarino: so there's two reasons i think matter (not everybody agrees!) -- one is that if you throw test vectors onto signet, it's much easier to actually validate them. we have lots of test vectors for taproot into core's internal tests, but actually making them available to other people to test their software isn't that easy; arguably that's part of why btcd had bugs recently
09:14 < LarryRuane> "why do it on signet, rather than just on regtest?" -- don't all softforks activate at block 1 on regtest, so we couldn't test that softfork upgrades go smoothly?
09:14 < _aj_> hernanmarino: another is that maybe it's interesting to do integration tests with different software, rather than running the entire environment yourself (since you can't make regtest available publicly without getting random reorgs)
09:14 < michaelfolkson> You don't ever see the activity on someone's regtest if we are interested in how a potential consensus change is being used to build things
09:14 < glozow> signet is more suitable for integration testing - you can have lots of companies, applications, different implementations/versions of LN nodes, etc. doing stuff on there at the same time
09:15 < hernanmarino> _aj_ : I agree on both, my original comment was referring to your second reason 
09:17 < _aj_> LarryRuane: you can use -vbparams to change when forks activate on regtest, if you want to test how upgrades go. but maybe that doesn't really test "smoothness" since it's all a very labratory environemnt
09:17 < _aj_> okay, before we go on, does anyone have any questions about how the heretical deployment idea works that they'd like to ask now?
09:18 < michaelfolkson> Why bother with signaling if every mined block needs to get signed by the block signer?
09:18 < _aj_> that's a good question!
09:19 < neha> i imagine because signaling is a very important thing to test...
09:19 < michaelfolkson> It is kinda testing signaling but in a completely different environment to what it would be on mainnet. No block signers on mainnet for one
09:19 < _aj_> the point of signalling is to be able to deal with custom signets -- if i'm pointing my inquistion node at one signet, how do i know when to enforce APO on it? you can't hardcode a time or height, because the signer might not have upgraded to enforce the rules at any particular time or height
09:20 < _aj_> neha: the signalling for heretical deployments is mostly different code to that used for mainnet, so it's not a super useful test in that sense :(
09:20 < LarryRuane> curious why `timeout` is a timestamp instead of block height? ... oh i think your last comment answers that question
09:20 < lightlike>  since the deployment mechanism is differerent (Heretical Deployment), I don't see much point in testing this.
09:20 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
09:21 < neha> _aj_: then i don't understand why you couldn't just go with "whenever the block signer says to enforce APO"
09:21 < _aj_> right -- so if you hardcoded signet's blockheight of 129000 to activate, then a custom signet would have to waste time mining 120k blocks just to catch up
09:21 < _aj_> neha: that's what's being signalled!
09:21 < neha> ah, ok
09:21 < glozow> so the reason is we have a method of communicating when to activate despite not everyone running the exact same software
09:22 < _aj_> neha: you just mine a single block with a particular version to signal activation or deactivation
09:22 < _aj_> which is a perfect lead in to...
09:22 < michaelfolkson> A custom signet is a totally different chain? What is its relevance to the default signet?
09:22 < _aj_> When have ANYPREVOUT and CHECKTEMPLATEVERIFY been activated on signet according to this logic? If we found a bug and needed to make substantial changes, how would we do that? Would that result in a signet hard fork?
09:22 < glozow> My node says CTV activated at height 106704
09:23 < _aj_> michaelfolkson: every signet shares the same genesis block, but every block after that is distinct due to the signet signature committing to the signet signing key
09:23 < glozow> no APO yet, I assume that'll be after PR #18?
09:23 < michaelfolkson> If I set up a custom signet with me as a block signer I control the block heights, times of when things are activated on my custom signet. But I don't care when things are activated on the default signet?
09:23 < _aj_> glozow: yes; or in the 23.0 branch
09:23 < lightlike> i found this quite confusing: it seems that in the PR branch neither have activated, in the 23 branch both have activated and in the 24.0 branch only CTV but not APO has activated. Is there a logic to this?
09:24 < glozow> My answer is from running my node on signet and calling getdeploymentinfo
09:24 < _aj_> lightlike: the 24.0 branch has [this PR] [CTV] merged, but [APO] unmerged, so the 24.0 branch is unable to tell you anything about APO
09:24 < glozow> ahhhh
09:25 < lightlike> _aj_: but why is [APO] only merged in 23 but not in 24?
09:25 < _aj_> https://github.com/bitcoin-inquisition/bitcoin/pull/18/commits/04683f69b5f503325610a6fac6379a8fd979d968 -- is the commit that sets APO up as an heretical deployment
09:26 < _aj_> lightlike: 24.0 is branched directly from core so doesn't include anything that inquisition merged for 23.0 until a PR gets merged. i'm trying to give a little time for people to review PR's before merging them
09:26 -!- dzxzg [~dzxzg@2600:387:f:6113::6] has quit [Quit: Client closed]
09:28 < roze_paul> @glozow, to be sure, your APO is also activated at 106704? My 23-node has both apo & ctv activated at 106704
09:28 < _aj_> so if you run `bitcoin-cli -signet getdeploymentinfo $(bitcoin-cli -signet getblockhash 106271)` you'll see CTV was signalled for activation at block height 105942
09:29 < _aj_> https://mempool.space/signet/block/105942?showDetails=true&view=actual#details -- which has the magic 0x60007700 version; 0x77 being 119, CTV's bip number
09:29 < _aj_> What is the point of the DEACTIVATING state?
09:30 < michaelfolkson> Phasing out a soft fork proposal (after a bug or just not being used)
09:30 < _aj_> why phase it out though? if there's a bug, why not just stop immediately?
09:31 < glozow> Is the question why we don't go directly from ACTIVE to ABANDONED, and have 432 blocks of DEACTIVATING isntead?
09:31 < _aj_> yep, that was the intent of the question
09:31 < roze_paul> +1.intermediate annulation of a softfork...waits until next period to be abandoned [inactive]
09:31 < michaelfolkson> I still don't understand the custom signet point. They share a genesis block. So what? :)
09:31 < neha> is it because of the interaction with timeout?
09:31 < glozow> I assumed it would have something to do with reorgs but I'm not sure :(
09:32 < michaelfolkson> But it seems like because of the custom signet point you want to coordinate phasing in and out of soft fork proposals
09:32 < d33r_gee> noob question: how do you compile a version of bitcoind (bitcoin-Inquisition) that's different from the regular main repo? More specifically can both instance run on the same machine?
09:32 < michaelfolkson> Rather than just having AJ announcing block heights, times of activations or deactivations
09:32 < _aj_> michaelfolkson: (there's no "so what" -- they share a genesis because that made it easier for wallets that wanted to hardcode the genesis and would have found it hard to deal with a different genesis for each custom signet)
09:33 < michaelfolkson> _aj_: Ok but after the genesis block they can be totally different chains? No?
09:33 < michaelfolkson> Totally independent other than the genesis block?
09:33 < _aj_> so it's an easier answer than that -- it's just to give people a chance to withdraw funds they might have locked into the soft fork. once the fork is deactivated or replaced, they might not be able to spend the funds at all (even if it's anyonecanspend that doesn't work if your tx gets rejected for not being standard)
09:33 < LarryRuane> d33r_gee: "can both instance run on the same machine?" -- yes
09:33 < _aj_> michaelfolkson: (they will always be totally different chains)
09:34 < roze_paul> @d33r_gee I've almost forgotten, but dm me later...it comes down to following the build directions and ensuring your data-dir isnt the same, IIRC
09:35 < LarryRuane> _aj_: that's interesting! to make sure I get it, funds on signet are somewhat precious (even tho of course no monetary value)?
09:35 < glozow> oh, duh
09:35 < roze_paul> (there are build directions on the bitcoin github page per mac/linux/win)
09:35 < _aj_> LarryRuane: well, not so much precious, as we'd like to not have useless entries sitting in the utxo set forever
09:35 < LarryRuane> oh right, +1
09:35 < d33r_gee> LarryRuane ah thanks!
09:35 < d33r_gee> roze_paul will do! Thank you!
09:35 < glozow> I had a question about abandoning, i.e. how it doesn't cause a hard fork. Is it because we are assuming everybody who followed the activation also followed the deactivation signaling? So there's nobody out there who activated the soft fork but won't also deactivate it?
09:36 -!- dzxzg [~dzxzg@2600:387:f:4b16::6] has joined #bitcoin-core-pr-reviews
09:36 < glozow> Well I guess it's signet so it's the same miner anyway
09:36 < _aj_> glozow: exactly -- the soft fork includes both the activation and deactivation as a bundle.
09:36 < glozow> gotcha
09:36 < michaelfolkson> glozow: It is a hard fork for those running an old version of bitcoin-inquisition not knowing about the attempt to phase it out
09:37 < instagibbs> it would be an end of "censorship" for those who don't know about the activation/deactivation
09:37 < glozow> there isn't a bitcoin-inquisition version that doesn't have both activation and deactivation logic tho
09:37 < _aj_> michaelfolkson: it's only a hardfork for people who've modified their inquisition software to not know about the deactivation signalling
09:38 < _aj_> Why is min_activation_height removed?
09:38 < michaelfolkson> _aj_: The deactivation signaling is included in the bitcoin-inquisition release with the activation signaling?
09:38 < LarryRuane> I remember luke-dashjr made this point about reducing the max block size -- it should be auto-expiring (deactivating) right from the start, so that the block size limit can be increased later without a hardfork, I though that was cool
09:38 < lightlike> because we don't need a configurable period between lock-in and activation in the new state model anymore - with heretical deployments, it activates automatically in the next period
09:38 < michaelfolkson> I thought for some soft fork proposals you wouldn't ever want to deactivate it
09:38 < _aj_> LarryRuane: yes; can you find where he wrote that? i looked the other day and couldn't remember
09:39 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
09:39 < glozow> michaelfolkson: observe that they are implemented in 1 commit
09:39 < _aj_> michaelfolkson: for mainnet activations you probably don't (or we haven't in the past anyway), but for signet-only activations, probably we always do
09:40 < _aj_> michaelfolkson: the signet miner can always choose not to signal for deactivation, of course
09:40 < LarryRuane> _aj_: not sure if I saw it written down, but it's in this presentation (which is really excellent in general, by the way) https://www.youtube.com/watch?v=CqNEQS80-h4
09:40 < _aj_> LarryRuane: oh! that would explain why i couldn't find it
09:41 < neha> https://diyhpl.us/wiki/transcripts/magicalcryptoconference/2019/why-block-sizes-should-not-be-too-big/
09:41 < _aj_> >> Why is min_activation_height removed? << -- anyone know the answer?
09:41 < glozow> I think lightlike said answered, there's no need to wait between lock in and activation?
09:42 < _aj_> oh, i'm blind, great!
09:42 < lightlike> that was my guess
09:42 < glozow> Also, just to clarify, even if no abandonment is signaled, the soft fork still eventually deactivates at the timeout right? https://github.com/bitcoin-core-review-club/bitcoin/blob/d3028d44d97629f821ea60c62515fd775a790f9b/src/versionbits.cpp#L79
09:42 < michaelfolkson> Definitely no deactivations for mainnet activations. Unless complete disastrous emergency. That would not be fun
09:42 < _aj_> also, because of the same problem above -- heights on signet in general don't work if you care about custom signets
09:43 < _aj_> glozow: yes, but i think the timeouts i put in for APO and CTV are in 2031, so...
09:43 < glozow> oh, haha
09:44 < _aj_> Why is Taproot buried?
09:44 < LarryRuane> because it was activated "long enough" ago?
09:45 < _aj_> that's a good reason, but not the reason!
09:45 < glozow> I think it's effectively buried already, but rpc/blockchain.cpp needs code that's going to be deleted to add Heretical Deployments?
09:45 < lightlike> because it' incompatible with the new heretical deployment scheme?
09:46 < _aj_> if you didn't bury it, you'd have to make it an heretical deployment; and that would (at least at one point) then mean that it would timeout eventually, but we don't want taproot to timeout
09:47 < michaelfolkson> You might want to sync up bitcoin-inquisition with the consensus rules of Core (and deactivate before 2031). Say if a opcode was given a different OP_NOP on bitcoin-inquisition to the one it ended up with in an actual soft fork activation in Core
09:47 < LarryRuane> can't you make timeout maxint? (0x7fff...)?
09:47 < _aj_> i think in the current code you could just make it be SetupDeployment({.always = true}) or so though...
09:47 < michaelfolkson> I guess we're not thinking particularly long term with default signet, bitcoin-inquisition. Happy to do resets
09:47 < _aj_> LarryRuane: yeah, exactly
09:48 < _aj_> michaelfolkson: presumably you'd want to test the OP_NOP/OP_SUCCESS in signet before activating it in core, so you'd deactivate the conflicting thing before that even
09:48 < _aj_> What is the purpose of AbstractThresholdConditionChecker and ThresholdConditionCache in versionbits.h?
09:50 < glozow> Abstract class for telling us the deployment status of a soft fork is, which can either be implemented through a version bits checker applying BIP9 / Heretical Deployment logic to blocks, a cache that just looks up the values, or something else.
09:50 < roze_paul> so the burying commit is by changing the timeout to maxint, or the bury is done in another way?
09:51 < _aj_> roze_paul: the burying is done by changing the activation method from BIP9 to just "it's active as of this height". for taproot and signet, the height has always been 0, so this is easy, even despite the custom signet problem we might have elsewhere. (taproot got merged into core just before signet did)
09:52 < _aj_> glozow: yep, pretty much; though i personally think the "abstract" is false advertising
09:52 < _aj_> Could/should the large commit be split up further? If so, how? If not, why not?
09:52 < theStack> is there any reason why taproot hasn't been buried yet in core?
09:52 < glozow> if anybody's interested, we've done a review club on burying deployments and deploymentstatus in the past https://bitcoincore.reviews/19438
09:53 < _aj_> theStack: see #23505 and other PRs
09:53 < _aj_> theStack: there's reasons, but no particularly profound ones?
09:54 < _aj_> (it did get split up further after those notes got written and gleb made some suggestions! maybe it could be more split up for next time?)
09:54 < michaelfolkson> It was buried, no? In #23536
09:54 < theStack> _aj_: oh interesting, apparently i even reviewed that one and can't remember :X
09:55 < theStack> the latest try seems to be https://github.com/bitcoin/bitcoin/pull/26201
09:55 < lightlike> There's also #26201 (open)
09:55 < michaelfolkson> Oh ok
09:55 < _aj_> Do any of the changes here make sense to include in Bitcoin Core?
09:56 < glozow> probably not?
09:57 < glozow> -renounce seems like it would be a footgun
09:57 < _aj_> Final questions that I skipped over are: "Were you able to compile and run the code?" "Were you able to test the code? What tests did you run?" -- happy to hang around if people want to discuss that beyond a y/n
09:57 < _aj_> glozow: i think some of the little bits of versionbits can be included -- removing the `params` arguments for AbstractThrCC
09:58 < michaelfolkson> I'm a bit scared running Bitcoin Core signet and bitcoin-inquisition on the same machine. Experienced any problems _aj_ switching between them on the same machine?
09:58 < roze_paul> I ran the code, not this pr specifically, just the main branch. Didn't run any tests iirc
09:58 < _aj_> michaelfolkson: i run them both with separate datadirs?
09:59 < roze_paul> +1 _aj_
09:59 < _aj_> glozow: https://github.com/ajtowns/bitcoin/commits/202301-versionbits has two commits i've been thinking about
10:00 < _aj_> michaelfolkson: if you want to meaningfully switch between them, running -rescan or -reindex is probably worthwhile, i guess?
10:00 < _aj_> okay, that's time!
10:00 < _aj_> #endmeeting
10:00 < glozow> thanks _aj_!
10:00 < _aj_> but still here for a little while if folks want to chat
10:00 < pablomartin_> thanks _aj_!
10:00 < lightlike> thanks _aj_ !
10:00 < theStack> thanks for hosting _aj_ 
10:01 < hernanmarino> This Review Club was very insightful for me , i had no idea of bitcoin-inquisition. Thanks _aj_ for all the work and for hosting 
10:01 < LarryRuane> Thank, aj, really interesting!
10:01 < roze_paul> thanks aj & everybody
10:02 < roze_paul> i'll still around and lurk, no questions rn
10:02 < michaelfolkson> _aj_: So it does full verification? I'm thinking two nodes running different consensus rules and passing blocks between eachother is a bit crazy. Especially if they disagree on a transaction being valid
10:03 -!- dzxzg [~dzxzg@2600:387:f:4b16::6] has quit [Quit: Client closed]
10:03 < _aj_> michaelfolkson: for blocks, as long as things are a soft fork, it should be fine -- massive bug if it's not, so finding such a thing would be great
10:04 < _aj_> michaelfolkson: for txs, if you've got an inquisition-only tx in your mempool (an APO or CTV spend eg), and then restart with core, the core node will drop that tx when reimporting mempool.dat because it's not standard, so you'll lose track of that tx, which may be annoying
10:06 < _aj_> wow, signet has ~700MB worth of blocks? that seems like a lot
10:06 < roze_paul> by 'restarting with core' you mean restarting on any build other than the one that was shutoff?
10:07 < michaelfolkson> roze_paul: Core's signet without the soft fork proposals that bitcoin-inquisition has
10:07 < michaelfolkson> So the Core repo rather than the bitcoin-inquisition repo
10:07 < _aj_> roze_paul: or any node software that doesn't have the same consensus/standardness rules. going from core version 24 or 0.20 or so (pre-taproot) eg?
10:07 < _aj_> "24 to 0.20 or so" i mean
10:08 < roze_paul> gotcha thx
10:10 < theStack> general question about expiring soft-forks: iirc one argument on the mailing list for them was to get rid of additional maintenance burden in the code-base. how would this make sense? the rules still have to stay in the code-base forever to verify the blocks on when the soft-fork was active, no?
10:10 < michaelfolkson> I'm not sold on the rationale for having signaling (custom signets) or the attempt to bake in deactivation (hard fork) logic without knowing what the future will hold. But not a massive deal with block signers. Can be changed in future
10:10 < theStack> (talking about core and mainnet here, obviously)
10:12 -!- jamesob [~jamesob@141.156.173.67] has quit [Read error: Connection reset by peer]
10:12 < _aj_> theStack: you could replace the code with "blocks up to 000000000000000000047de8c79bc9d8b954dd14a334ec06f8035a77532b40db are valid" -- a deep reorg wouldn't have to comply with those rules then
10:12 < _aj_> theStack: we have hardcoded exceptions in place for bip16 and taproot on mainnet, which is kind-of similar (except much more constrained and going in the opposite direction, where the rules are enforced more now than they were at the time)
10:12 < theStack> _aj_: ah okay. so it'd only run during IBD, and in no other context
10:14 -!- jamesob [~jamesob@141.156.173.67] has joined #bitcoin-core-pr-reviews
10:14 < michaelfolkson> It would require checkpoints and/or an assumption that there wouldn't be massive re-orgs
10:15 < _aj_> theStack: yeah, i dunno, maybe it doesn't make sense if you try to work through the details?
10:15 < michaelfolkson> They're a terrible idea on mainnet unless you believe Core is an authoritative source on the consensus rules at any point in time and Core will always make the right decisions
10:16 < michaelfolkson> Any UASF, URSF etc talk and it becomes a massive mess (even more so with an added chaos path of deactivation or no deactivation)
10:18 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:18 < theStack> _aj_: hm have to think more about it, at least i know now the idea behind that argument
10:18 -!- roze_paul [~quassel@132.216.191.43] has quit [Ping timeout: 260 seconds]
10:19 < _aj_> theStack: i guess the argument is "okay, we had 300kB blocks from 2026 to 2028, now we don't have those rules, but the blocks are already there. if you manage to reorg them, we're not going to stop you from making them big, but you could just build big ones on top of the regular chain, so whatever" ?
10:21 < _aj_> theStack: (the "just have a temporary soft fork" argument feels a lot weaker to me for any fork that would affect actual transaction validity, and  thus could cause people to lose money)
10:22 -!- roze_paul [~quassel@132.216.191.43] has joined #bitcoin-core-pr-reviews
10:25 -!- pablomartin_ [~pablomart@185.169.233.59] has quit [Ping timeout: 248 seconds]
10:26 < _aj_> okay, it's past 04:20 so must be fair to be faded now, thanks for coming y'all, and peace out!
10:26 < theStack> _aj_: oh okay, i wasn't specifically talking about the block-size-decrease, but expiring soft-forks in general (i think i saw the idea popping up in context of CTV last year)
10:27 < theStack> _aj_: thanks a lot
10:40 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
10:42 < michaelfolkson> Thanks _aj_!
11:08 -!- roze_paul [~quassel@132.216.191.43] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
11:09 -!- roze_paul [~quassel@132.216.191.43] has joined #bitcoin-core-pr-reviews
11:14 -!- roze_paul [~quassel@132.216.191.43] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
11:25 -!- hh41 [~hh@14.139.241.212] has joined #bitcoin-core-pr-reviews
11:46 -!- hh41 [~hh@14.139.241.212] has quit [Quit: Connection closed]
12:08 -!- b_101_ [~robert@185.242.5.35] has quit [Quit: Lost terminal]
12:19 -!- kevkevin [~kevkevin@c-98-226-43-69.hsd1.il.comcast.net] has quit [Quit: Connection closed]
12:49 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 252 seconds]
13:04 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has quit [Ping timeout: 248 seconds]
13:22 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has joined #bitcoin-core-pr-reviews
13:42 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has quit [Ping timeout: 248 seconds]
14:17 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
14:19 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
14:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4125:ef70:81ec:6465] has quit [Remote host closed the connection]
14:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:f4c0:3ec4:a8b4:2a61] has joined #bitcoin-core-pr-reviews
14:24 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
14:54 -!- __gotcha [~Thunderbi@ldd29-1-78-210-28-87.fbx.proxad.net] has joined #bitcoin-core-pr-reviews
15:13 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has joined #bitcoin-core-pr-reviews
15:42 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
16:03 -!- __gotcha [~Thunderbi@ldd29-1-78-210-28-87.fbx.proxad.net] has quit [Ping timeout: 268 seconds]
18:22 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
18:24 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
18:25 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Client Quit]
18:25 -!- ariard [~ariard@167.99.46.220] has quit [Ping timeout: 255 seconds]
18:26 -!- ariard [~ariard@167.99.46.220] has joined #bitcoin-core-pr-reviews
18:26 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
18:42 -!- Yihen [~textual@122.115.32.55] has quit [Ping timeout: 268 seconds]
18:43 -!- FrancisMr [~MrFrancis@2001:8a0:fa4c:901:64b2:b6fb:932d:5d06] has quit [Ping timeout: 252 seconds]
18:46 -!- Yihen [~textual@122.115.32.55] has joined #bitcoin-core-pr-reviews
19:13 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews
19:13 -!- ariard_ [~ariard@167.99.46.220] has joined #bitcoin-core-pr-reviews
19:15 -!- Netsplit *.net <-> *.split quits: sanket1729, brunoerg, djinni`, ariard
19:27 -!- Netsplit over, joins: brunoerg, djinni`
21:06 -!- hernanmarino [~hernanmar@181.99.169.107] has quit [Ping timeout: 268 seconds]
21:24 -!- BUSY [~BUSY@user/busy] has quit [Ping timeout: 252 seconds]
21:27 -!- dongcarl [~dongcarl@cpe-66-65-184-36.nyc.res.rr.com] has quit [Ping timeout: 255 seconds]
21:37 -!- BUSY [~BUSY@user/busy] has joined #bitcoin-core-pr-reviews
22:13 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
22:14 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
23:00 -!- dongcarl [~dongcarl@66.65.169.19] has joined #bitcoin-core-pr-reviews
23:40 -!- Livestradamus [~Livestrad@user/livestradamus] has quit [Quit: ~Peace~]
23:41 -!- Livestradamus [~Livestrad@user/livestradamus] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Feb 09 00:00:39 2023