--- Log opened Wed May 03 00:00:50 2023
00:41 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
00:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 260 seconds]
00:52 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
00:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 248 seconds]
00:58 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
01:02 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
01:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
02:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
02:11 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
02:15 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
02:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
02:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 240 seconds]
02:50 -!- Mercury_ [~root@31.125.90.17] has quit [Remote host closed the connection]
03:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
03:04 -!- __gotcha [~Thunderbi@88.182.109.149] has joined #bitcoin-core-pr-reviews
03:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 265 seconds]
03:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
03:08 -!- __gotcha [~Thunderbi@88.182.109.149] has quit [Ping timeout: 240 seconds]
03:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
03:25 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
03:28 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-pr-reviews
03:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
03:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 265 seconds]
03:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
03:36 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 240 seconds]
03:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 250 seconds]
03:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
03:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
04:02 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
04:06 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
04:19 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
04:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 246 seconds]
04:47 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
04:51 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
05:02 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-pr-reviews
05:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
05:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Remote host closed the connection]
05:59 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
06:03 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
06:24 -!- jonatack1 [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.8]
06:27 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
06:38 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Ping timeout: 260 seconds]
07:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has joined #bitcoin-core-pr-reviews
07:30 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews
07:38 -!- wim99 [~wim@77-166-139-117.fixed.kpn.net] has joined #bitcoin-core-pr-reviews
07:38 -!- wim99 [~wim@77-166-139-117.fixed.kpn.net] has quit [Client Quit]
07:38 -!- wim96 [~wim96@77-166-139-117.fixed.kpn.net] has joined #bitcoin-core-pr-reviews
07:38 -!- wim96 [~wim96@77-166-139-117.fixed.kpn.net] has quit [Client Quit]
09:00 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has quit [Quit: You have been kicked for being idle]
09:52 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 240 seconds]
09:52 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:54 -!- sebastianvanstaa [~sebastian@ip-095-223-106-175.um35.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews
09:56 -!- guest96 [~guest@136.53.35.244] has joined #bitcoin-core-pr-reviews
09:57 -!- guest96 [~guest@136.53.35.244] has quit [Client Quit]
09:57 -!- guestguest [~guestgues@136.53.35.244] has joined #bitcoin-core-pr-reviews
09:58 -!- kevkevin [~kevkevin@c-98-226-43-69.hsd1.il.comcast.net] has joined #bitcoin-core-pr-reviews
09:59 < glozow> ping
09:59 < theStack> pong
09:59 < sebastianvanstaa> hey
09:59 < glozow> thanks :D
09:59 < sipa> pang
09:59 -!- abubakarsadiq [~abubakars@102.91.49.158] has joined #bitcoin-core-pr-reviews
10:00 < kevkevin> plong
10:00 < glozow> #startmeeting
10:00 < kevkevin> hey
10:00 < glozow> Hi everyone! Welcome to PR Review Club. Feel free to say hi so we know you're here. Any first-timers?
10:00 < abubakarsadiq> hi
10:01 < glozow> We're looking at #27501, add getprioritisationmap, delete a mapDeltas entry when delta==0 today
10:01 < glozow> Notes and questions in the usual place: add getprioritisationmap, delete a mapDeltas entry when delta==0
10:01 < LarryRuane> hi
10:01 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
10:01 < glozow> oops bad copypaste. https://bitcoincore.reviews/27501
10:02 < glozow> Did y'all get a chance to review the PR and/or look at the notes? How about a y/n
10:02 < LarryRuane> y notes and questions, n for review, but I'd love to review this
10:02 < kevkevin> very briefly will be mostly spectating today
10:03 < sebastianvanstaa> y notes and questions
10:03 < abubakarsadiq> yes i read the notes
10:03 < yashraj> notes & qns
10:04 < LarryRuane> concept and approach ACK
10:04 < glozow> Great to hear! Can somebody summarize what this PR does?
10:04 -!- tobses [~tobses@102.88.45.240] has joined #bitcoin-core-pr-reviews
10:05 -!- Jeff71 [~Jeff@ip72-197-225-40.sd.sd.cox.net] has joined #bitcoin-core-pr-reviews
10:05 -!- Netsplit *.net <-> *.split quits: jess, jnewbery, harding, avril
10:05 -!- harding_ [quassel@newmail.dtrt.org] has joined #bitcoin-core-pr-reviews
10:05 -!- jnewbery_ [~john@user/jnewbery] has joined #bitcoin-core-pr-reviews
10:06 < abubakarsadiq> added an rpc to get entries of mapDeltas and also remove a transaction from the mapDelta entries when it's delta fee is 0
10:06 < LarryRuane> It keeps `mempool.dat` cleaner by removing unnecessary entries (i.e. ones that have zero delta)
10:06 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:06 < glozow> abubakarsadiq: yes!
10:06 -!- Netsplit over, joins: jess
10:06 < kevkevin> Creates a new rpc to get mapdeltas and removes any entry with delta==0
10:06 -!- Netsplit over, joins: avril
10:06 -!- tobses [~tobses@102.88.45.240] has quit [Client Quit]
10:07 < glozow> LarryRuane: yes that is the overarching goal, to clean stuff up
10:07 < glozow> kevkevin: yep!
10:07 < kevkevin> question? what are map deltas exactly?
10:07 < glozow> That's the first question!
10:07 < theStack> the pr enables users of the prioritisetransaction RPC (i.e. miners) the possibility to 1) inspect the current map of prioritised txs with a new RPC and 2) also delete them from the map if delta is zero again
10:07 < glozow> What is mapDeltas? Why does it exist?
10:07 < glozow> Here is where it is declared in the code: https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/txmempool.h#L450
10:08 -!- tobses [~tobses@102.88.45.240] has joined #bitcoin-core-pr-reviews
10:08 < glozow> theStack: yes exactly
10:08 < sebastianvanstaa> for a miner to prioritize transactions without changing the (on-chain) financial incentive (i.e fee)
10:09 < LarryRuane> mapDeltas allows the node user to artificially modify a transaction's fee which would affect fee estimation, eviction decisions, mining decisions and probably a few other things
10:09 < glozow> sebastianvanstaa: LarryRuane: yes! except prioritisetransaction does not affect the fee estimator.
10:10 < LarryRuane> theStack: yes, and IIUC, this new RPC won't tell us anything we *couldn't* already know, if we kept track somehow separately, but since the node already knows it, it's helpful for it to be able to provide it
10:10 < LarryRuane> glozow: ah +1 thanks
10:10 -!- tobses [~tobses@102.88.45.240] has quit [Client Quit]
10:10 -!- remix [~remix@141.84.69.77] has joined #bitcoin-core-pr-reviews
10:11 < glozow> How is an entry added to `mapDeltas`? When is it removed?
10:11 < sebastianvanstaa> added with prioritizetransaction RPC
10:11 < LarryRuane> and just to confirm... when we *relay* a tx, we don't relay it with its different fee... because that would change the txid! 
10:11 < abubakarsadiq> the entries of mapDelta is transactionID with the current fee right?
10:11 < kevkevin> is it added by using prioritisetransaction? and removed when delta==0
10:12 < LarryRuane> I think it's added here: https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/txmempool.cpp#L854
10:12 < yashraj> prioritisetransaction RPC call? removed on node restart?
10:12 -!- remix [~remix@141.84.69.77] has quit [Client Quit]
10:12 < sebastianvanstaa> removed when tx mined in a block or conflicted
10:12 < LarryRuane> taking advantage of the behavior of `std::map` that if you access a key that doesn't exist, it gets created as a side-effect -- is that right?
10:12 < sipa> LarryRuane: You should think of the RPC as informing bitcoind of the fact that if somehow that transaction gets mined, *you* (the node owner) gets paid out of band.
10:12 < sebastianvanstaa> kevkevin i think it is not removed when delta==0. Hence the new PR
10:13 < kevkevin> sebastianvanstaa ohh sorry question was for current functionality
10:13 -!- tobses [~tobses@102.88.45.240] has joined #bitcoin-core-pr-reviews
10:13 < glozow> Yeah the transaction itself is *not* modified. If miners could do that and add fees to transactions, I think Bitcoin would be broken.
10:13 < LarryRuane> sipa: +1 thanks
10:14 < abubakarsadiq> sebastianvanstaa: what does conflicted means, an identical transaction with higher fee rate?
10:14 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:14 < glozow> abubakarsadiq: no, the fee is a delta, not the current fee. It's what's added on top.
10:14 < LarryRuane> (or subtracted)
10:14 < LarryRuane>  well sorry, it's always added, but could be < 0 haha
10:15 < glozow> sebastianvanstaa: correct, it is only removed when the tx is confirmed or conflicted by a block. Another case is if its value is 0 and you restart.
10:15 < sebastianvanstaa> abubakarsadiq not sure what 'conflicted' encompasses. Maybe gloria can shed some light
10:16 < glozow> and yes everybody is correct, the way to add a delta is to call prioritisetransaction or to load a mempool.dat that contains deltas in it
10:16 < kevkevin> does conflicted mean that the uxto was spent already? and thus invalid
10:16 < glozow> LarryRuane: right! the delta can be negative. So theoretically miners can use this to block transactions from their mempools
10:17 < glozow> kevkevin: yes, "conflicted by a block" means a conflicting transaction (i.e. spending one or more of the same UTXOs) has been confirmed.
10:17 < sebastianvanstaa> kevkevin (y)
10:17 < sebastianvanstaa> LarryRuane: can they? not sure
10:18 < LarryRuane> glozow: that's interesting! they don't really have a way to remove a tx from the mempool, if they want to censor it, so this gives them a means to the same end (not that we like censoring)
10:18 < sebastianvanstaa> I think it would stay in the mempool, just not included in a block
10:18 < sebastianvanstaa> So, censoring, yes
10:19 < abubakarsadiq> well if its deducted to zero will be removed
10:19 < LarryRuane> abubakarsadiq: oh you're right
10:19 < glozow> Yeah they would stay in the mempool unless it fills up and we start evicting the low-feerate transactions. The modified feerate is used in that algo, so we'll evict those "de-prioritised" ones.
10:19 < yashraj> is this rpc for miners?
10:19 < sebastianvanstaa> abubakarsadiq the mapDelta entry, not the transaction would be removes
10:20 < sebastianvanstaa> *removed
10:20 < glozow> yashraj: yes. I can't think of a use case for non-mining nodes to use this.
10:20 < sipa> Apart from testing the mining code, perhaps.
10:20 < sipa> But yes, I'd say it's intended for miners.
10:20 < glozow> haha, yes
10:21 < yashraj> thank you
10:21 < glozow> Can `mapDeltas` contain an entry for a transaction that isn't in the mempool?
10:21 < LarryRuane> in general, we'd like to not encourage miners to get payments out of band (even though no way to prevent it, of course), IIUC
10:21 < sebastianvanstaa> glozow yes it can
10:21 < LarryRuane> glozow: yes! that's why the delta isn't stored in the actual mempool entry
10:21 < sipa> Of course, ideally miners don't get paid out of band at all for transactions; it removes the ability for the public P2P network to e.g. estimate fees.
10:22 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
10:22 < glozow> LarryRuane: Yes, I agree. Ideally the public p2p network is a fair, fee-based auction in which everybody knows what the "going rate" is and has the ability to bid.
10:22 < sipa> But it was at some point obvious that miners were accepting out of band payments anyway.
10:22 < glozow> sebastianvanstaa: LarryRuane: correct
10:22 < LarryRuane> sipa: so for example if our standardness rules are too tight, that might be a bad thing if it encourages more out-of-band transactions.. but if they're too loose, then there's a possible DoS vector!
10:23 < sipa> Exactly.
10:23 < glozow> Why shouldn't we delete a transaction's entry from `mapDeltas` when it is replaced or expired?
10:23 < LarryRuane> balancing act :)
10:23 < abubakarsadiq> so that if it appears again it will maintain its priority
10:24 < LarryRuane> glozow: because it could come back again.. if we didn't retain it in `mapDeltas`, the user would have to prioritize it again
10:24 < glozow> abubakarsadiq: LarryRuane: right!
10:24 < glozow> Why should we allow prioritising a transaction that isn’t present in the mempool?
10:25 < LarryRuane> but i do have a question on this point... if a tx is removed due to it appearing in a block, but then that block is reorged out (rollback), then we would forget its prioritization, right? (but maybe that's rare enough we don't care)
10:25 < kevkevin> because it may not be present in our mempool but may be in someone else's?
10:25 < kevkevin> and thus might appear again
10:25 < sebastianvanstaa> why not? It could show up any time
10:25 < theStack> LarryRuane: heh, wanted to ask the same
10:25 < LarryRuane> glozow: because it's not in the mempool YET
10:25 < glozow> LarryRuane: yes I think we're expecting that to be really really rare.
10:25 -!- tobses [~tobses@102.88.45.240] has quit [Ping timeout: 240 seconds]
10:26 < sipa> If someone paid to get their transaction prioritized, and the block is then reorged out, they should pay for prioritization again!
10:26 < LarryRuane> i almost wonder if it could be, after the tx is 6 or some number of blocks deep, only THEN remove it from mapDeltas?
10:26 < abubakarsadiq> glozow: but when that happen it losses it's priority
10:26 < glozow> Here's the PR that added the removal logic: https://github.com/bitcoin/bitcoin/pull/6464. There is some discussion about when we should/shouldn't remove an entry there.
10:26 < LarryRuane> sipa: good point!
10:26 < glozow> I imagine at the time, this was sufficient to make sure mapDeltas was always cleaned up (?). We didn't have RBF at the time.
10:27 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
10:28 < LarryRuane> Oh Luke makes a good point on the PR you just linked to, that we need a separate map because if the tx isn't already in the mempool, it may not be able to *enter* on its own fee
10:28 < sebastianvanstaa> LarryRuane(y)
10:29 < LarryRuane> sipa: although I guess it depends on how they were paid (out of band) ... if a Visa payment, then may not need to be redone
10:29 < sebastianvanstaa> (y)  I meant
10:30 < glozow> What is the problem if we don't clean up `mapDeltas`?
10:31 < kevkevin> we will have a bunch of useless mapDeltas because the transactions are already confirmed or conflicted
10:31 < LarryRuane> excess memory usage? (but that doesn't seem like it would be a major problem)
10:31 < sebastianvanstaa> every byte counts!
10:31 < sebastianvanstaa> to keep HW requirements as low as possible
10:31 < abubakarsadiq> transactions with 0 delta will be sitting there which is of no use, since they are no longer a priority.
10:32 < glozow> Yeah, essentially it's a waste of memory
10:32 < LarryRuane> i had another question, how often is `mapDeltas` written out to `mempool.dat`? is it only on clean shutdown? Or periodically?
10:33 < LarryRuane> if only on clean shutdown, then the prioritising would have to be redone after restart i guess
10:33 < LarryRuane> sorry i mean, after non-clean restart
10:33 < glozow> 2 places. On shutdown (unless you configure otherwise) and if you call the savemempool RPC
10:33 < LarryRuane> glozow: thanks
10:34 < glozow> You can grep for `DumpMempool`: https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/kernel/mempool_persist.h#L16
10:34 < LarryRuane> perhaps miners run a cron job to run `savemempool` ... or maybe after each prioritization
10:35 < kevkevin> what happens when `mapDeltas` are written out to `mempool.dat` like what is changed in `mempool.dat`?
10:35 < glozow> Why?
10:36 < glozow> kevkevin: sorry, I don't follow what the question is?
10:36 < abubakarsadiq> can we set a negative delta for a transaction
10:36 < glozow> yes
10:37 < LarryRuane> (was that question to me?) well because if the node shuts down uncleanly, the user won't have to remember all the prioritizations that were done ... but i know non-clean shutdown is very rare
10:37 < glozow> Oh I see. That's a good question to think about: today, if you're a miner, how do you clean up `mapDeltas`?
10:37 < kevkevin> glozow I just saw that mapDeltas are written out to `mempool.dat` I thought they were separate. Do the `mapDeltas` change `mempool.dat` in anyway?
10:38 < glozow> (My guess is the answer is "you don't")
10:38 < glozow> kevkevin: oh I see. Yes, they are part of mempool.dat!
10:38 < abubakarsadiq> 0 fee delta will remove it from mapDeltas  is it the same with negative?
10:38 < kevkevin> glozow ohh ok thanks
10:39 < kevkevin> abubakarsadiq wouldn't negative still be valid if we want to deprioritize a transaction?
10:40 < glozow> abubakarsadiq: 0 fee delta only removes it from mapDeltas when you're loading: https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/kernel/mempool_persist.cpp#L76-L78
10:40 < abubakarsadiq> What is mapDeltas? Why does it exist?
10:40 < glozow> negative delta would be something you still want to keep, i don't think it makes sense to just delete it if it's negative
10:40 < abubakarsadiq> sorry copy paste, not a question
10:41 < LarryRuane> back to question 3 for a second, another place entries are added to `mapDeltas` is on restart: https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/txmempool.cpp#L854
10:41 < abubakarsadiq> thanks glowzow, kevkevin
10:41 < glozow> kevkevin: you can see mapDeltas being written to the file here: https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/kernel/mempool_persist.cpp#L166
10:42 < theStack> interesting that the mempool serialization was never changed to not serialize 0 fee delta entries in the first place (but only ignore them on loading)
10:43 < glozow> Anybody have any ideas on the last question? If you're a miner today, how might you clean up mapDelats?
10:43 < kevkevin> glozow gotcha and DumpMempool is only used when we call savemempool or on shutdown
10:43 < glozow> kevkevin: yep!
10:43 < LarryRuane> glozow: that code you just linked to, interesting that it's only writing out `mapDelta` entries that are NOT in the mempool?
10:43 < LarryRuane> see 4 lines above that line, the call to `mapDeltas.erase()`
10:44 < glozow> LarryRuane: for entries in the mempool, there is an `nFeeDelta` field serialized alongside the transaction https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/kernel/mempool_persist.cpp#L162
10:44 < kevkevin> glozow no idea either do nothing or delete all mapDeltas?
10:44 < glozow> LarryRuane: also note that, in that function, `mapDeltas` is a local copy of the mempool's mapDeltas and goes out of scope at the end of the function
10:44 < sebastianvanstaa> glozow restart the client now and then? (bad idea , I know)
10:45 < LarryRuane> glozow: +1 thanks
10:45 < theStack> sebastianvanstaa: +1, that would be also my answer
10:46 < theStack> (or well, restart bitcoind, not the client)
10:46 < glozow> kevkevin: sebastianvanstaa: kind of. I think the only way to do it is to keep track of every time you've called prioritisetransaction and when the entries would be deleted, then "cancel" the stale ones by setting the delta to 0 and then restarting your node.
10:46 < LarryRuane> yes so this is a very useful PR!
10:46 < sebastianvanstaa> but restarting your node would certainly lead to loss of mining profits, right?
10:47 < LarryRuane> sebastianvanstaa: really good point!
10:47 < glozow> yeah, so my guess is it's just not cleaned up lol
10:47 < LarryRuane> probably miners are using beefy machines with tons of memory so isn't a practical problem
10:47 < sebastianvanstaa> theStack yes I meant bitcoind
10:48 < glozow> well, if mapDeltas is huge, it cuts into your 300MB max mempool
10:48 < sebastianvanstaa> just increase it's size then :)
10:49 < glozow> Ok so after this PR, if you're a miner, how would you clean up your mapDeltas?
10:49 < LarryRuane> glozow: oh, interesting, that mempool limit applies to this map as well, didn't know that
10:50 < glozow> see `CTxMemPool::DynamicMemoryUsage`: https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/txmempool.cpp#L959
10:50 < kevkevin> would we just call prioritisetransaction and set the delta to 0
10:50 < kevkevin> because of this bit of code
10:50 < kevkevin> https://github.com/bitcoin/bitcoin/pull/27501/files#diff-c065d4cd2398ad0dbcef393c5dfc53f465bf44723348892395fffd2fb3bac522R873-R878
10:50 < LarryRuane> glozow: +1 thanks
10:51 < glozow> kevkevin: yes and how would you know what arguments to call prioritisetransaction with?
10:51 < theStack> i'd use the new fancy RPC call to see what the current delta for a given tx is, and then call prioritisetransaction with that value negated to set it to zero again... aaand it's gone
10:51 < sebastianvanstaa> glozow first use the RPC added by this PR to get a list of all priritized transactions, of course :)
10:51 < glozow> theStack: bingo
10:51 < kevkevin> you would first call getpriotisationmap to know how much to move the delta?
10:53 < glozow> yep yep
10:53 < glozow> Ok that's all the questions I prepared. Sounds like everybody understands the PR so I'll be expecting your reviews soon ;)
10:53 < kevkevin> would it not make sense to also be able to just remove a transaction from the mapDelta and not have to call two rpc's to achive that, not sure if I'm missing why not have the ability to do so
10:54 < glozow> kevkevin: are you suggesting a `clearallprioritisation` RPC?
10:54 < sebastianvanstaa> new PR coming up !
10:55 < kevkevin> glozow: yea that or to be able to clear a specific prioritisation
10:55 < glozow> kevkevin: how do you know which specific transactions to clear?
10:55 < LarryRuane> txid?
10:56 < kevkevin> glozow: the same way we call prioritisetransaction
10:56 < glozow> then you have to remember that it's in your mapDeltas?
10:57 < kevkevin> well I guess the other way would be to call getprioritisationmap but we already do that with this PR haha
10:57 < glozow> jnewbery suggested to me offline that perhaps we could implicitly interpret `prioritisetransaction(txid, 0, delta=0)` as "clear prioritisation." I think that could be an extra simplification.
10:58 -!- guestguest [~guestgues@136.53.35.244] has quit [Quit: Connection closed]
10:58 < kevkevin> glozow: ya I think that would be better than a whole new rpc
10:58 < sebastianvanstaa> glozow yes that would make sense
10:59 < glozow> Anyway, maybe for a followup. It could be a "userspace break" so I won't throw it in this PR
10:59 < LarryRuane> someone earlier asked if probably only miners would use `"prioritisetransaction` .. i noticed that that PRC is in `rpc/mining.cpp` so that tell you something!
10:59 < abubakarsadiq> +1 i think it will will be better to remove a transaction in one call
10:59 < glozow> Thanks for coming everyone! See you next week!
10:59 < theStack> i think both the new RPC and the implicit "clear prioritisation" idea have value
10:59 < glozow> #endmeeting
10:59 < theStack> thanks for hosting glozow!
10:59 < LarryRuane> thanks, @glozow this was great!!
11:00 < kevkevin> Thanks for hosting glozow
11:00 < LarryRuane> and thanks to everyone else for the great discussion!
11:00 < sebastianvanstaa> thanks glozow, for hosting! That was fun today
11:00 < abubakarsadiq> thanks for your answers everyone.
11:00 < yashraj> good meeting, thanks glozow
11:00 < abubakarsadiq> thanks for hosting glozow
11:00 < sebastianvanstaa> and everyone else :)
11:00 < yashraj> where can I read about more about rationale for prioritisetransaction rpc? sorry off topic but didn't find much on internet search I see it's pretty old.
11:01 < kevkevin> yashraj: you can find the function here https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/txmempool.cpp#L850
11:01 < kevkevin> also the rpc is here
11:01 < kevkevin> https://github.com/bitcoin/bitcoin/blob/1d7f1ada48083d27adda47e04fd0311cc3cd6816/src/rpc/mining.cpp#L447
11:02 -!- Jeff71 [~Jeff@ip72-197-225-40.sd.sd.cox.net] has quit [Quit: Ping timeout (120 seconds)]
11:02 < yashraj> thanks kevkevin: I was looking for rationale/more context since I don't understand it well
11:04 -!- sebastianvanstaa [~sebastian@ip-095-223-106-175.um35.pools.vodafone-ip.de] has quit [Quit: Connection closed]
11:09 -!- abubakarsadiq [~abubakars@102.91.49.158] has quit [Read error: Connection reset by peer]
11:16 -!- kevkevin [~kevkevin@c-98-226-43-69.hsd1.il.comcast.net] has quit [Ping timeout: 246 seconds]
11:44 -!- ___nick___ [~quassel@host81-148-218-251.range81-148.btcentralplus.com] has joined #bitcoin-core-pr-reviews
12:27 -!- __gotcha [~Thunderbi@88.182.109.149] has joined #bitcoin-core-pr-reviews
12:28 -!- ___nick___ [~quassel@host81-148-218-251.range81-148.btcentralplus.com] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
12:30 -!- ___nick___ [~quassel@host81-148-218-251.range81-148.btcentralplus.com] has joined #bitcoin-core-pr-reviews
12:31 -!- ___nick___ [~quassel@host81-148-218-251.range81-148.btcentralplus.com] has quit [Client Quit]
12:33 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:33 -!- ___nick___ [~quassel@host81-148-218-251.range81-148.btcentralplus.com] has joined #bitcoin-core-pr-reviews
13:03 -!- ___nick___ [~quassel@host81-148-218-251.range81-148.btcentralplus.com] has quit [Ping timeout: 240 seconds]
13:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:dd35:a263:914b:9ff1] has quit [Remote host closed the connection]
13:10 -!- __gotcha [~Thunderbi@88.182.109.149] has quit [Ping timeout: 268 seconds]
13:31 -!- __gotcha [~Thunderbi@88.182.109.149] has joined #bitcoin-core-pr-reviews
13:35 -!- __gotcha [~Thunderbi@88.182.109.149] has quit [Ping timeout: 268 seconds]
13:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
13:50 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit [Remote host closed the connection]
13:52 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
14:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
14:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
14:44 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:12 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
15:16 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
15:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
15:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 260 seconds]
15:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
15:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 248 seconds]
15:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
15:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 248 seconds]
15:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
16:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
16:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
16:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 248 seconds]
16:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
16:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
16:50 -!- grettke [~grettke@184.55.131.155] has quit [Remote host closed the connection]
16:51 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
17:03 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
17:09 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
17:24 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
17:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
17:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 248 seconds]
17:38 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
18:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
18:08 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
18:10 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
18:23 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
18:24 -!- grettke [~grettke@184.55.131.155] has quit [Client Quit]
18:43 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
18:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
18:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
19:11 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:16 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
19:26 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
19:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
19:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
19:45 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:50 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
20:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
20:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 250 seconds]
20:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
20:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 260 seconds]
21:06 -!- b_101 [~robert@189.236.59.209] has quit [Ping timeout: 240 seconds]
21:11 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:16 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
21:30 -!- b_101 [~robert@189.236.59.209] has joined #bitcoin-core-pr-reviews
21:35 -!- b_101 [~robert@189.236.59.209] has quit [Ping timeout: 268 seconds]
22:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
22:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
22:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
22:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 246 seconds]
22:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
22:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
22:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
22:51 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 250 seconds]
22:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has joined #bitcoin-core-pr-reviews
23:02 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:4453:70a1:fac9:eff9] has quit [Ping timeout: 240 seconds]
23:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
23:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
--- Log closed Thu May 04 00:00:52 2023