--- Log opened Wed Apr 26 00:00:45 2023
00:18 -!- martinus [~martinus@046125249120.public.t-mobile.at] has quit [Remote host closed the connection]
01:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
03:40 -!- tobedeleted [~tobedelet@host86-164-118-65.range86-164.btcentralplus.com] has joined #bitcoin-core-pr-reviews
03:41 -!- tobedeleted [~tobedelet@host86-164-118-65.range86-164.btcentralplus.com] has quit [Client Quit]
03:59 -!- tobedeleted [~tobedelet@host86-164-118-65.range86-164.btcentralplus.com] has joined #bitcoin-core-pr-reviews
04:00 -!- tobedeleted [~tobedelet@host86-164-118-65.range86-164.btcentralplus.com] has quit [Client Quit]
07:09 -!- abubakarsadiq [~abubakars@197.210.77.203] has joined #bitcoin-core-pr-reviews
07:36 -!- jess [meow@libera/staff/cat/jess] has joined #bitcoin-core-pr-reviews
07:54 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has quit [Quit: __gotcha]
07:55 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
08:18 -!- abubakarsadiq [~abubakars@197.210.77.203] has quit [Read error: Connection reset by peer]
08:37 -!- abubakarsadiq [~abubakars@197.210.53.139] has joined #bitcoin-core-pr-reviews
08:41 -!- abubakarsadiq [~abubakars@197.210.53.139] has quit [Ping timeout: 240 seconds]
08:48 -!- abubakarsadiq [~abubakars@197.210.77.32] has joined #bitcoin-core-pr-reviews
08:56 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
08:57 -!- abubakarsadiq [~abubakars@197.210.77.32] has quit [Read error: Connection reset by peer]
09:05 < LarryRuane> we'll be starting in just under an hour https://bitcoincore.reviews/27460
09:11 -!- abubakarsadiq [~abubakars@197.210.76.162] has joined #bitcoin-core-pr-reviews
09:12 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
09:15 -!- abubakarsadiq [~abubakars@197.210.76.162] has quit [Read error: Connection reset by peer]
09:19 -!- abubakarsadiq [~abubakars@197.210.53.40] has joined #bitcoin-core-pr-reviews
09:45 -!- abubakarsadiq [~abubakars@197.210.53.40] has quit [Ping timeout: 252 seconds]
09:47 -!- abubakarsadiq [~abubakars@197.210.52.223] has joined #bitcoin-core-pr-reviews
09:49 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
09:50 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:53 -!- guestguestguest [~guestgues@136.53.35.244] has joined #bitcoin-core-pr-reviews
09:54 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
09:57 -!- svanstaa [~svanstaa@ip-095-223-106-175.um35.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews
09:59 -!- turkycat [~turkycat@76.146.17.180] has joined #bitcoin-core-pr-reviews
10:00 < LarryRuane> #startmeeting
10:00 < michaelfolkson> hi
10:00 < LarryRuane> Hi everyone, welcome! Today we'll be discussing https://bitcoincore.reviews/27460
10:00 < abubakarsadiq> hi
10:00 < svanstaa> hi
10:00 < LarryRuane> Feel free to say hi to let everyone know you're here
10:01 < LarryRuane> any review club first-timers here?
10:01 < michaelfolkson> Quiet today
10:01 < ccdle12> hi
10:01 < effexzi> Hi every1 
10:01 < turkycat> hello everyone
10:02 < LarryRuane> yes, I think there's some meeting going on that many of the usuals are busy with
10:02 -!- AlexWiederin [~AlexWiede@business-24-134-211-65.pool2.vodafone-ip.de] has joined #bitcoin-core-pr-reviews
10:03 < LarryRuane> Today's PR is pretty simple, so I added a few notes items that aren't directly related to the PR, but just for discussion, background, and learning
10:03 < LarryRuane> any questions about the notes, or is there anything I got wrong, or you'd like to expand on?
10:04 < LarryRuane> I'm not an expert on the mempool, so I may have made some mistakes :)
10:05 < michaelfolkson> No first thought was what people will use this for but that's question 3
10:05 < LarryRuane> One thing I'd like to make special mention of is the link provided in the first note: https://bitcoinsearch.xyz/?q=mempool ... I wasn't aware of that myself until putting together these notes
10:05 < LarryRuane> It seems to be a nice way to search the mailing list discussions!
10:06 -!- yashraj [~yashraj@146.70.198.38] has joined #bitcoin-core-pr-reviews
10:06 < LarryRuane> Yes, Michael, we can discuss that right now, what are the use cases for this proposed feature?
10:07 < michaelfolkson> No sorry, you can keep to the order :)
10:07 < LarryRuane> Or actually, first, what is being proposed here, what is the feature?
10:07 < LarryRuane> haha okay, let's first ask, did anyone have a chance to review the PR?
10:07 < svanstaa> importting mempool.dat via RPC as opposed to copying it into the .bitcoin dir
10:08 < svanstaa> yes
10:08 < abubakarsadiq> tested ACK the PR 
10:08 < svanstaa> built and ran the tests
10:08 < LarryRuane> svanstaa: good! how does one use the RPC interface to do this, what exactly is the interface?
10:09 < LarryRuane> I guess I'm asking, what are the arguments to this new RPC?
10:09 < abubakarsadiq> this PR add rpc call for importing transactions in a mempool.dat file into a node mempool
10:09 < svanstaa> bitcoin-cli  importmempool path/mempool.dat
10:10 < michaelfolkson> svanstaa: On running the tests https://bitcoin.stackexchange.com/questions/98911/should-i-run-the-tests-every-time-i-review-an-open-bitcoin-core-pr
10:10 < turkycat> no, didn't have time to review this week.
10:11 -!- jamesob4 [~jamesob@141.156.173.67] has joined #bitcoin-core-pr-reviews
10:11 < LarryRuane> svanstaa: thanks for that link, I hadn't seen that, looks very helpful
10:11 < svanstaa> not sure about the meaning of the boolean arguments though
10:11 -!- jamesob9 [~jamesob@141.156.173.67] has quit [Ping timeout: 276 seconds]
10:11 -!- jamesob [~jamesob@141.156.173.67] has quit [Ping timeout: 264 seconds]
10:11 -!- jamesob4 is now known as jamesob
10:11 < michaelfolkson> svanstaa: Basically try to go a little further and fiddle around with the relevant tests a bit. Just running them can be of limited value. But doesn't hurt to obvs
10:12 -!- jamesob9 [~jamesob@141.156.173.67] has joined #bitcoin-core-pr-reviews
10:12 < LarryRuane> maybe we can take a little diversion, why should reviewers test a PR when CI is already doing so?
10:12 < svanstaa> @Larry it was Michael who posted the link, not me
10:14 < michaelfolkson> It can be helpful on strange OSes, strange hardware if not overlapping with CI
10:14 < LarryRuane> yes, good answer by michael, his SE answer kind of covers what I was asking
10:15 < LarryRuane> also as he says there, it's good to modify the tests slightly if you have enough understanding to do so, and that may uncover new problems
10:15 < michaelfolkson> Yup. Especially as tests are changed in this PR
10:15 < LarryRuane> I also like running the tests in debuggers (both on the python test and on bitcoind itself) and look around at various points along the execution of the tests, to see if things are as expected by my understanding
10:16 < LarryRuane> michaelfolkson: +1
10:16 < LarryRuane> let's go back in history a ways, question 2, What are the advantages of persisting the mempool to disk?
10:17 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Ping timeout (120 seconds)]
10:17 < abubakarsadiq> to recover the mempool after restart
10:17 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
10:18 < LarryRuane> abubakarsadiq: yes, and why is that useful?
10:19 < LarryRuane> actually an even more basic question (i remember wondering this myself when first getting started), why do full nodes even need a mempool *if they're not mining*?
10:20 < LarryRuane> it's pretty obvious that miners need a mempool (to assumble a non-empty block so they can get the fees), but why do non-mining nodes want to maintain a mempool? there is some cost, after all
10:21 < turkycat> so that nodes can verify the transactions in a block. a single transaction doesn't contain key info like the amount of the input being spent or the scriptPubkey for that input. each node can independently verify that an input isn't a double spen
10:21 < abubakarsadiq> I might be wrong, since the received broadcasted transaction why not keep it, not to verify it twice when the received new blocks, some transactions in the block might be in their mempool
10:22 < michaelfolkson> Some argue they don't need to :) But more efficient if they have already verified all the transactions in a block before they receive details of a mined block
10:22 < LarryRuane> turkycat: I don't think that's correct, because there's a separate "coins" database that all full nodes maintain, and that's independent of the mempool, and the coins db is how double-spending is detected
10:22 -!- ccdle1270 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
10:22 < AlexWiederin> Agree with abubakarsadiq! Probably also reduces the "noise" of transactions going around if only transactions that are not in the mempool are forwarded to peers
10:23 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
10:23 < AlexWiederin> But not entirely sure
10:23 < LarryRuane> michaelfolkson: yes, that's a great reason ... there's a feature called compact blocks, and the reason they're compact is it's assumed that the receiver of the compact block has already seen and verified the "missing" transactions because they're in the mempool
10:24 < LarryRuane> another reason to have a mempool even if you're not mining is fee estimation ... if your own node is contructing a transaction, it needs to decide on a competitive fee
10:25 < LarryRuane> you don't want to either underpay or overpay ... the mempool helps a lot with that
10:25 < turkycat> I didn't know about the coins db, where is that located? (bit of an aside)
10:26 < turkycat> I thought there was only blocks, rev, chainstate, and indexes (including txindex if enabled)
10:26 < LarryRuane> abubakarsadiq: yes, there's a script verification "cache" that prevents us from having to re-verify transactions that we've already verified (i don't know much detail on that)
10:26 < LarryRuane> turkycat: it's in the `chainstate` subdirectory of the data directory
10:27 < turkycat> thanks
10:27 < LarryRuane> oh you mentioned it already, ... it's not the most intuitively named!
10:28 < LarryRuane> also i think having mempools within full nodes helps with transaction relay, as @AlexWiederin said (i think)
10:28 < LarryRuane> so if we don't persist the mempool to disk, then when we restart, we'd have the problems we just mentioned, because we have forgotten all about the mempool
10:29 < abubakarsadiq> why does it require upto 300mb as default
10:29 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:29 < LarryRuane> michaelfolkson: you may know this, correct me if i'm wrong, but maintaining a mempool also lets us construct transactions that use unconfirmed (mempool) transactions as inputs
10:30 < LarryRuane> abubakarsadiq: that's a great question! I have an idea, but anyone else want to answer that?
10:31 < michaelfolkson> LarryRuane: Huh yeah hadn't thought of that. If the parent transaction wasn't created by our wallet I guess. The wallet would trust transactions it itself had constructed
10:31 < LarryRuane> abubakarsadiq: yes the 300mb mempool size, my first impression is it seems kind of small by today's hardware standards, doesn't it?
10:32 < abubakarsadiq> for me it's kind of too much
10:32 < LarryRuane> that 300mb is *memory* size, by the way, not just the sum of the transactions as they appear on the wire or on disk ... the memory size is quite a bit larger, anyone know why?
10:32 < LarryRuane> *sum of the transactions SIZES i should have said
10:33 < svanstaa> because deserialized transactions take up more space
10:35 < LarryRuane> svanstaa: yes exactly! in C and C++, `struct` variables often have "holes" in them because of alignment requirements.. so for example, if an object is a byte plus an 8-byte integer, that serialzes to a 9-byte stream ...
10:35 < svanstaa> abubakarsadiq 300MB is less than 100 blocks... it happens that it gets filled up completely
10:35 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has quit [Ping timeout: 255 seconds]
10:36 < LarryRuane> but when stored in memory, the struct is padded out to the "alignment" of the struct, which in this case would be 8 bytes, so that struct would need 16 bytes in memory
10:37 < svanstaa> Is there a reaon why it is 300MB? Or just an arbitrary value? Would it hurt to increase the default value?
10:37 < LarryRuane> svanstaa: yes, that 300mb translates to i think around 150mb of transactions, which is somewhere around 100 blocks as you say, maybe a little less
10:38 < LarryRuane> so if we go with a rough estimate of 100 blocks worth of transactions, that's a LOT of blocks, the next block will be constructed from around the top 1% (by fee) of the mempool
10:39 < LarryRuane> in other words, 300mb is a lot from that perspective (which is what @abubakarsadiq said too)
10:39 < michaelfolkson> Just a default obvs, the user can lower it 
10:40 < LarryRuane> svanstaa: i think the 300mb is a balance between nodes having a mempool that is pretty similar to miners' mempools, and also being a size that most nodes (even on a raspberry pi) can do
10:40 < LarryRuane> miners have an incentive to have a larger mempool, can anyone say why?
10:40 < yashraj> why does -blocksonly lower it all the way to 5 MB?
10:41 < AlexWiederin> LarryRuane to pick the one with the best fees?
10:41 < AlexWiederin> *pick the ones
10:41 < svanstaa> LarryRuane larger pool to pick high fee tranascations from
10:41 < svanstaa> *transactions
10:41 < LarryRuane> AlexWiederin: yes but, even with a 300MB mempool, they're only taking roughly the top 1%, so that will be the same even with a 500mb mempool
10:42 < LarryRuane> i think the reason may be (or at least one i thought of) is in case there are no new transactions being generated for an extended period of time, just a dropoff in demand...
10:43 < svanstaa> so what happens if my mempool is full, and I see another (high  fee) transaction incoming, would my node replace one of the txns currently in the mempool?
10:43 < michaelfolkson> yashraj: Blocksonly doesn't participate in transaction relay https://bitcoin.stackexchange.com/questions/114081/what-is-the-difference-between-blocksonly-and-block-relay-only-in-bitcoin-core
10:43 < LarryRuane> the mempool will slowly shrink as miners produce blocks ... so a miner would hate to completely run out of transactions to include in the block, because they'd like to get at least SOME fees
10:44 < LarryRuane> michaelfolkson: thanks, that's a very good one!
10:44 < yashraj> ah crap, thanks michael
10:45 < michaelfolkson> yashraj: So yeah just verifying blocks right Larry? Not maintaining a mempool?
10:45 < LarryRuane> block explorer nodes, by the way, usually run a larger mempool, right now https://mempool.space/ shows that the mempool is 279 out of 300mb
10:45 < michaelfolkson> If no mempool only needs something minimal like 5MB
10:45 < LarryRuane> but i've seen recently where the mempool size is greater than 300, it might say 400 / 300
10:46 < LarryRuane> the way that explorer knows that is by running a larger mempool
10:47 < LarryRuane> because of the inscription stuff going on recently, the mempool has exceeded 300mb (for those nodes that configured a higher value, obviously)
10:47 < LarryRuane> what happens if a node receives more transactions that it can fit in its mempool?
10:47 < LarryRuane> *than it can fit
10:48 < svanstaa> yeah that was my question. Does it kick out lower fee txns in favour of higher fee ones?
10:48 -!- abubakarsadiq [~abubakars@197.210.52.223] has quit [Read error: Connection reset by peer]
10:48 < yashraj> kick lower fees ones?
10:48 < LarryRuane> yashraj: yes, exactly... technically, the lowest *feerate* transactions are dropped
10:49 < svanstaa> that way 300MB should be completely sufficient
10:49 -!- abubakarsadiq [~abubakars@197.210.53.40] has joined #bitcoin-core-pr-reviews
10:49 < LarryRuane> and https://mempool.space/ actually tells you the min feerate needed to stay in a 300mb mempool
10:50 < yashraj> of course, thanks.
10:50 < michaelfolkson> I think package relay would incentivize the need for larger default mempools if your machine can handle it, not resource constrained
10:50 < abubakarsadiq> a basic question, what will make a transaction to be dropped from the mempool
10:51 < michaelfolkson> Ideally you'd keep those low fee transactions around rather than booting them
10:51 < svanstaa> are we going to talk about the PR a little more? I was wondering about the meaning of these options: use_current_time
10:51 < svanstaa> apply_fee_delta_priority
10:51 < svanstaa> apply_unbroadcast_set
10:51 < LarryRuane> @michaelfolkson pointed out that the mempool size is configurable, but there's an advantage to leaving it default (even if you have a lot of memory), which is that your mempool will be similar to that of other nodes, and that makes fee estimation more accurate, and tx relay more efficient
10:51 < LarryRuane> svanstaa: yes, sorry! all these sidetracks ... anyone want to say what those options are for?
10:52 < LarryRuane> i can answer the first one, the mempool records the time each tx entered, because when a tx gets to be 2 weeks old, it gets dropped, no matter what its feerate is
10:52 < LarryRuane> (and even if there's room to keep it)
10:53 < LarryRuane> so when you're importing a mempool, do you want to reset the tx entrance times to the current time? or use the times stored in the imported mempool.dat?
10:53 < LarryRuane> i think the author of the PR wanted to let the user decide
10:53 < abubakarsadiq> i dont know about use_current_time but apply_fee_rate option to true means the transactions will be prioritize based delta fee, while importing transactions with high delta fee rates are prioritize
10:53 < LarryRuane> (in some situations one might be better than the other, or opposite)
10:54 < svanstaa> so default is true:  use the current system time
10:54 < svanstaa> which means the txns are made to appear like they have just been broadcasted?
10:55 < LarryRuane> so there's an RPC to artifically change a mempool tx's feerate, `prioritisetransaction`
10:55 < LarryRuane> svanstaa: yes ... so it's as if they've been been relayed to us over the p2p network
10:56 < svanstaa> and this would 'extend' the expiry date of two weeks. In which circumstances is this favourable?
10:56 < abubakarsadiq> apply_unbroadcast_set option to true, while importing  unbroadcasted transactions will be added to ubroadcast set, if it's false it will not be added
10:56 < LarryRuane> this `prioritisetransaction` value (per-tx) is also stored in `mempool.dat`, so do we want to import those from the file? or let them be zero?
10:56 < svanstaa> why extend their lifetime?
10:57 < LarryRuane> svanstaa: i don't know, guess it depends on exactly why you're importing transactions in the first place
10:57 < LarryRuane> abubakarsadiq: yes ... what are unbroadcast transactions, anyone?
10:58 < svanstaa> feels like you are pouring zombie transactions into the network, but thats just my gut feeling :)
10:58 < svanstaa> got to ask Marco about it
10:58 < LarryRuane> yes you could ask on the PR
10:58 < LarryRuane> why is `use_current_time` defaulting to true?
10:59 < michaelfolkson> We didn't answer the use case question yet right? I'm assuming testing, I can't think of why a user would want to do this
10:59 < yashraj> maybe i kicked low-fee-rate txs coz memool was full, now it's empty so give them another chance?
11:00 < LarryRuane> michaelfolkson: thanks, good point.. I think it may be if you're an enterprise and want to spin up a new node, and make it effective ASAP... you could copy a mempool.dat from one of your existing nodes
11:00 < abubakarsadiq> Unbroadcast transactions are transactions that have been created and signed but not yet broadcasted to the network, how do they get to the mempool?
11:00 < LarryRuane> welp, guess that's all we have time for
11:00 < LarryRuane> #endmeeting
11:00 < michaelfolkson> LarryRuane: Ok, thanks
11:00 < LarryRuane> but feel free to stick around (i will) to keep discussing
11:00 < svanstaa> thanks, everyone :)
11:00 < LarryRuane> sorry we didn't have time to get through all the questions
11:01 < yashraj> great stuff thanks :larryruane I loved the mini-detours
11:01 < AlexWiederin> Thanks all
11:02 < abubakarsadiq> larryRuane:thanks
11:02 < yashraj> thanks :michael gotta read that SE answer again
11:02 < LarryRuane> abubakarsadiq: unbroadcast has a very specific meaning, see this answer by @michaelfolkson https://bitcoin.stackexchange.com/questions/107214/what-does-unbroadcast-mean-what-does-it-mean-for-a-transaction-to-be-successful
11:02 < michaelfolkson> yashraj: Sure don't expect you to be able to read it during the meeting :)
11:03 < michaelfolkson> (For later)
11:03 < LarryRuane> yes @michaelfolkson does an amazing job on stackexchange!
11:03 < michaelfolkson> Maybe if your mempool was corrupted you'd want to import a different mempool from another of your nodes. Can't imagine that happens too much
11:04 < michaelfolkson> LarryRuane: Ha thanks
11:04 -!- AlexWiederin [~AlexWiede@business-24-134-211-65.pool2.vodafone-ip.de] has quit [Quit: Connection closed]
11:04 < michaelfolkson> I'll ask on the PR, people on the PR seem to want it
11:04 < LarryRuane> michaelfolkson: regarding your SE answer there about unbroadcast ... is that concept only applicable to transactions that WE originate?
11:04 < LarryRuane> michaelfolkson: +1
11:05 -!- guestguestguest [~guestgues@136.53.35.244] has quit [Quit: Connection closed]
11:06 < michaelfolkson> LarryRuane: Yeah I think so. You don't care really if it isn't your transaction
11:06 < michaelfolkson> Not your responsibility. But if your transaction isn't propagating that is your problem
11:06 < abubakarsadiq> thanks for the link larryRuane
11:06 < LarryRuane> got it, that makes sense.. if we received the tx on the p2p network (not one we're originating), then we know that it has been relayed (at least to us)
11:07 < michaelfolkson> Yeah "initial broadcast"
11:07 < michaelfolkson> LarryRuane: Right
11:07 -!- ccdle1270 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed]
11:08 < abubakarsadiq> +1 michealfolkson: i understand
11:09 < LarryRuane> what about question 4: How large is the mainnet mempool.dat file on your system? Does this size differ significantly from the -maxmempool setting? If so, why?
11:09 -!- svanstaa [~svanstaa@ip-095-223-106-175.um35.pools.vodafone-ip.de] has quit [Quit: Connection closed]
11:09 < LarryRuane> on my system, it's only 89mb
11:10 < abubakarsadiq> I did not check that on mine
11:10 < yashraj> checking
11:10 < abubakarsadiq> currently on signet for testing purposes
11:11 < LarryRuane> which is only only about 29% of 300mb ... so most of the 300mb is indeed deserialization overhead, and also (forgot to mention this earlier), index overhead (because lots of fast lookups are needed for mempool items)
11:11 < LarryRuane> there's a complicated map (container) that lets you look up mempool txes in various ways, such as largest feerate
11:12 < yashraj> wtf is happening with mine? node window says 277 MB...the file itself only 131 KB
11:13 < LarryRuane> oh wait sorry, on that system (with the 89mb mempool.dat), the configuration is: `maxmempool=250`
11:13 < LarryRuane> (this is a raspi system, so not a lot of memory, they reduce it slightly)
11:14 < LarryRuane> so the mempool.dat file size is 35% of 300mb (not 29% as i said earlier)
11:15 < LarryRuane> yashraj: what is your `maxmempool`?
11:15 < LarryRuane> is that what "node window" means? i'm not familiar with "node window"
11:16 < yashraj> haha when I press cmd+I in gui
11:16 < yashraj> Information tab on that window
11:16 < LarryRuane> oh i almost never use the gui, i should try that
11:16 < LarryRuane> you can look for `maxmempool` in your bitcoin.conf file, what does it say?
11:17 < yashraj> it's not set in my conf file...so default?
11:18 < abubakarsadiq> if it's not set then it's probably the default
11:18 < LarryRuane> yes, then default, 300
11:18 < LarryRuane> 141kb is incredibly small!
11:18 < LarryRuane> is that mainnet?
11:18 < LarryRuane> if it's regtest or testnet or signet, then it might make sense
11:19 < yashraj> mainnet...block height shows 787114
11:20 < yashraj> is my OS counting it differently?
11:20 < LarryRuane> are you running `ls -l` on the mempool.dat file?
11:21 < LarryRuane> (to get that number, 141kb)
11:23 < yashraj> was doing it from Finder but running ls -l gives similar value
11:25 < LarryRuane> try `bitcoin-cli getmempoolinfo`, what does that say?
11:28 < yashraj> RPC tells me "size": 129831, "usage": 274325152, "maxmempool": 3000000
11:29 < yashraj> not sure what size means
11:31 -!- abubakarsadiq [~abubakars@197.210.53.40] has quit [Read error: Connection reset by peer]
11:33 -!- martinus [~martinus@046125249120.public.t-mobile.at] has joined #bitcoin-core-pr-reviews
11:34 < LarryRuane> i think size is the number of transactions
11:34 < LarryRuane> is there a "bytes" value shown?
11:34 < yashraj> "bytes" : 47345422
11:36 < LarryRuane> i think that's large your mempool is configured to be, that's even greater than the default?
11:37 < yashraj> what does that mean? maxmempool is 300 usage is ~270 what is bytes?
11:38 < LarryRuane> oh wait here's what we should look at: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/mempool.cpp#L691
11:38 < yashraj> also found this: https://developer.bitcoin.org/reference/rpc/getmempoolinfo.html
11:39 < LarryRuane> good find, that's easier to read!
11:39 < yashraj>                 {RPCResult::Type::NUM, "bytes", "Sum of all virtual transaction sizes as defined in BIP 141. Differs from actual serialized size because witness data is discounted"},  so witness stuff is causing this?
11:40 < yashraj> mismatch is count
11:41 < LarryRuane> your "usage" seems about right.. (274 mb or so)
11:42 < LarryRuane> the in-memory mempool doesn't get flushed out until you shut down the node, can you do a clean shutdown and see if the file size increases?
11:43 < yashraj> bingo, now shows 94 MB
11:44 < yashraj> had this qn for the past half hour that why're we looking at mempool.dat if the mempool is in memory?
11:44 < LarryRuane> cool! so maybe when your node started the previous time, it wasn't fully synced with the blockchain?
11:45 < yashraj> how did you get the right number straight away?
11:45 < LarryRuane> my node was already synced
11:45 < yashraj> mine was synced too
11:45 < LarryRuane> (the most recent time it shutdown)
11:45 < LarryRuane> hmm i don't know then what's going on
11:45 < yashraj> oh
11:47 < LarryRuane> actually i'm not sure if the mempool gets flushed out to disk (mempool.dat) other than shutdown... I've been looking at the coins db recently (the chainstate), and i may be getting these two mixed up in my mind
11:47 < LarryRuane> the coins db doesn't get flushed except during shutdown, that i'm sure of
11:48 < yashraj> hmm, right when I shut down the node I saw a temp file like mempool.dat.new or something for a sec then the file size bumped to 94MB
11:53 < LarryRuane> that makes sense, it writes a new file and then renames it, in case the process (or entire system) crashes halfway through the writes
11:53 < LarryRuane> the way it's done prevents file corruption
11:54 < yashraj> great stuff
11:54 < yashraj> these sessions are a gold mine, thanks for engaging and helping me understand this!
11:54 < yashraj> pardon the metaphor
12:10 < LarryRuane> you're very welcome! haha yes, maybe we should start saying bitcoin mine!
12:53 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
13:22 -!- svanstaa [~svanstaa@45.128.199.76] has joined #bitcoin-core-pr-reviews
13:23 -!- svanstaa [~svanstaa@45.128.199.76] has quit [Client Quit]
13:44 -!- svanstaa [~svanstaa@ip-095-223-106-175.um35.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews
14:24 -!- yashraj [~yashraj@146.70.198.38] has quit [Remote host closed the connection]
14:58 -!- svanstaa [~svanstaa@ip-095-223-106-175.um35.pools.vodafone-ip.de] has quit [Ping timeout: 246 seconds]
15:00 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:07 -!- martinus_ [~martinus@046125249034.public.t-mobile.at] has joined #bitcoin-core-pr-reviews
15:10 -!- martinus [~martinus@046125249120.public.t-mobile.at] has quit [Ping timeout: 255 seconds]
16:06 -!- martinus__ [~martinus@046125249096.public.t-mobile.at] has joined #bitcoin-core-pr-reviews
16:09 -!- martinus_ [~martinus@046125249034.public.t-mobile.at] has quit [Ping timeout: 276 seconds]
17:11 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 250 seconds]
17:19 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
17:26 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 265 seconds]
17:31 -!- yashraj [~yashraj@146.70.198.39] has joined #bitcoin-core-pr-reviews
17:33 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
18:13 -!- yashraj [~yashraj@146.70.198.39] has quit [Remote host closed the connection]
18:25 -!- yashraj [~yashraj@146.70.198.38] has joined #bitcoin-core-pr-reviews
19:41 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
19:48 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
19:53 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
19:59 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
20:32 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
20:38 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
20:47 -!- yashraj [~yashraj@146.70.198.38] has quit [Remote host closed the connection]
20:48 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
20:54 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
21:02 -!- grettke [~grettke@184.55.131.155] has quit [Remote host closed the connection]
21:05 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
21:25 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
22:12 -!- turkycat [~turkycat@76.146.17.180] has quit [Quit: Ping timeout (120 seconds)]
22:47 -!- dongcarl [~dongcarl@cpe-66-65-169-19.nyc.res.rr.com] has quit [Quit: Ping timeout (120 seconds)]
22:47 -!- dongcarl1 [~dongcarl@cpe-66-65-169-19.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews
22:48 -!- dongcarl1 is now known as dongcarl
23:06 -!- yashraj [~yashraj@146.70.198.38] has joined #bitcoin-core-pr-reviews
23:07 -!- yashraj [~yashraj@146.70.198.38] has quit [Remote host closed the connection]
--- Log closed Thu Apr 27 00:00:45 2023