--- Log opened Wed Jun 22 00:00:59 2022
00:12 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
00:17 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 268 seconds]
00:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
00:49 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 248 seconds]
01:19 -!- Bayer[m] [~bayernato@2001:470:69fc:105::2:1665] has joined #bitcoin-core-pr-reviews
01:29 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
01:33 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 268 seconds]
01:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
02:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 255 seconds]
02:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
02:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 244 seconds]
02:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
02:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 248 seconds]
02:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
02:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 240 seconds]
02:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
02:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 264 seconds]
02:49 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
02:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 240 seconds]
02:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
03:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 268 seconds]
03:06 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
03:10 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 264 seconds]
03:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
03:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 268 seconds]
03:28 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
03:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 248 seconds]
03:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
03:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 268 seconds]
03:50 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
03:54 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
04:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
04:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 255 seconds]
04:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
04:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 268 seconds]
04:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
04:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 240 seconds]
04:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
04:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 264 seconds]
04:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
04:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Ping timeout: 240 seconds]
05:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has joined #bitcoin-core-pr-reviews
06:05 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
06:53 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 268 seconds]
07:13 -!- cangr [~root@static.120.240.69.159.clients.your-server.de] has joined #bitcoin-core-pr-reviews
07:16 -!- Guest82 [~Guest82@p5083df83.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews
07:17 -!- cangr [~root@static.120.240.69.159.clients.your-server.de] has quit [Client Quit]
07:24 -!- Guest82 [~Guest82@p5083df83.dip0.t-ipconnect.de] has quit [Quit: Client closed]
08:07 -!- afmencken [~afmencken@192.252.212.14] has joined #bitcoin-core-pr-reviews
09:20 < MacroFake> We'll get started in about 40 minutes
09:30 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:40 -!- afmencken [~afmencken@192.252.212.14] has quit [Ping timeout: 256 seconds]
09:43 -!- afmencken [~afmencken@192.252.212.38] has joined #bitcoin-core-pr-reviews
09:49 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:55 -!- amirreza [~amirreza0@89.219.86.232] has joined #bitcoin-core-pr-reviews
09:58 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:58 -!- amirreza [~amirreza0@89.219.86.232] has quit [Client Quit]
10:00 < MacroFake> Hi
10:00 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
10:00 < MacroFake> #startmeeting
10:00 < svav> Hi all
10:00 < michaelfolkson> hi
10:00 < BlueMoon> Hello!!
10:00 < dunxen> hi!
10:00 -!- Amirreza [~Amirreza7@89.219.86.232] has joined #bitcoin-core-pr-reviews
10:00 < MacroFake> Anyone here for the first time?
10:01 < afmencken> Hi, I'm a first timer
10:01 < Amirreza> MacroFake, Me
10:01 < Amirreza> Hello
10:01 < larryruane> hi
10:01 -!- sam81 [~sam@ch-va-93622ff000-405632-1.tingfiber.com] has joined #bitcoin-core-pr-reviews
10:01 < MacroFake> afmencken: Amirreza: Nice, and welcome
10:01 < Amirreza> MacroFake: Thanks
10:02 -!- sanya [~sanya@109-93-70-113.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
10:02 < MacroFake> to get started, you may also share whether you reviewed the pr (y/n). https://bitcoincore.reviews/23418 
10:02 < effexzi> Hello every1
10:02 -!- yashraj [~yashraj@2607:fea8:8602:500:5992:1813:f818:b5af] has joined #bitcoin-core-pr-reviews
10:03 < Amirreza> MacroFake: no
10:03 -!- dpr54 [~dpr54@154.0.128.44] has joined #bitcoin-core-pr-reviews
10:03 < svav> n but I read the notes
10:03 < larryruane> y
10:03 < dunxen> y
10:03 -!- paul_c [~paul_c@pool-74-96-221-100.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:03 -!- tru3nrg [~tru3nrg@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
10:03 < effexzi> Y
10:03 < paul_c> Hey everyone
10:04 < dpr54> hi
10:04 < MacroFake> ok, if there are any questions later, just go ahead and ask
10:04 < Bayer[m]> hello!
10:04 < MacroFake> Let's jump in: What does the prioritisetransaction RPC do?
10:04 < svav> afmencken: where did you hear about this meeting please?
10:05 < svav> prioritisetransaction Gives a fee value in satoshis to add or subtract to the existing fee value. It’s a value to modify the absolute fee of the TX. It is not paid initially itself, but only considered by the algorithm that selects transactions into a block as it means the transaction will pay a higher or lower absolute fee.
10:05 < MacroFake> svav: Correct
10:05 < michaelfolkson> Just for miners right when constructing the block to mine?
10:05 < larryruane> I think it's a way to change a mempool transaction's effective fee (thus feerate) ... hence the name, you can increase it's probability of being included in a block (if you're a miner)
10:06 < larryruane> *effective fee meaning not its actual fee, but how it's treated in the mempool
10:06 < MacroFake> michaelfolkson: Good q. I think it is also used for relay. But let me double check...
10:07 < michaelfolkson> I'd guess it wouldn't be particularly helpful for relay. Sure you propagate it but your peers still won't include it in their mempool or propagate it further?
10:07 < svav> prioritisetransaction gives the value of the fee adjustment to reprioritise the transaction, right? It is considered by the transaction selection algorithm, because it means an adjusted absolute fee will be taken, if the transaction is actually selected.
10:08 < MacroFake> michaelfolkson: Actually for relay the normal fee is used
10:08 < MacroFake> https://github.com/bitcoin/bitcoin/blob/b9122e95f0f4ff5d2b2e21a5caf6c69d488c0347/src/txmempool.h#L241-L260
10:09 < Amirreza> It may seem very basic question, so sorry to ask. Why we should use an RPC to modify the TRX fee? Why not sending a second TRX with higher fee? If we are lucky, the first TRX would accept (which has less fee) and if no, the second would be included in the block.
10:10 < michaelfolkson> Amirreza: This isn't actually modifying the fee. It is pretending the fee is higher so that it is treated differently
10:10 < dpr54> interesting
10:10 < larryruane> Amirreza: It's the miner who is using this RPC, on a transaction that they likely didn't create
10:10 < michaelfolkson> So I think you are asking why use RBF (replace-by-fee) which isn't related to this PR? :)
10:10 < MacroFake> Amirreza: Good question. This is primarily supposed to be used by miners to prioritise a transaction.
10:11 < larryruane> If we have time, I would like to understand better the motivation for the use of this RPC
10:11 < sanya> what reasons they might have to prioritise certain transaction?
10:12 < MacroFake> They may have been paid out-of-band
10:12 < afmencken> I'm trying to imagine a use case for this - the first one that comes to mind is if a miner has some out of band incentive to (de)prioritize the transaction.
10:12 < MacroFake> Or it is one of their own txs, for example a pool payout tx
10:12 < larryruane> If someone submits a tx and it's not getting mined, I suppose the tx sender could pay a miner on the side to mine it, and the miner would do that using this RPC?
10:13 < larryruane> (oh marco just said that :) )
10:13 < Amirreza> Sorry I don't get it. What I interpret by the name, it should sort TRXs by fee rat in descending order. Because miners want TRXs with higher fees. Is this correct?
10:13 < Amirreza> fee rate*
10:14 < larryruane> Amirreza: That is correct -- this gives the miner a way to modify that selection decision (for just themself)
10:14 < michaelfolkson> Amirreza: They generally do want transactions with the highest fee rates yes. But occasionally like in examples described above they'll want to force a transaction into a block even if it has lower fee rate
10:15 < Amirreza> larryruane: michaelfolkson: thanks I get it
10:15 < svav> Who gets to use prioritisetransaction, is it just a miner?
10:16 < MacroFake> svav: Anyone can use it. It will also prevent the tx to "fall off" when the prioritization puts it above the minimum mempool fee 
10:17 < MacroFake> However, your peers may reject the transaction if it doesn't meet their minimum mempool fee
10:17 < MacroFake> Let's go on: Were you able to compile Bitcoin Core with the signed-integer-overflow sanitizer? Were you able to reproduce the bug manually by calling the RPC or by running the fuzz test?
10:18 < larryruane> yes! and even better, the bug doesn't reproduce with the PR!
10:18 < svav> So is it just a way to make it more or less likely a transaction gets included in a block, after you have submitted the transaction for processing, i.e. its in the mempool already?
10:18 < MacroFake> larryruane: Thanks for testing
10:18 < MacroFake> svav: Only if your node creates blocks (or block templates that get mined on)
10:18 < larryruane> tiny question, when building for fuzzing, is there no bitcoind?
10:20 < MacroFake> larryruane: There won't be a bitcoind if you pass --enable-fuzz (to link a fuzz engine), however the fuzz tests are also built (by default) along with all other stuff without a fuzz engine
10:20 < afmencken> svav: I think at better way to say it is that it is a way to increase the likelihood that the transaction stays in _your_ mempool (but not necessarily into a block).
10:21 < svav> OK thanks
10:21 < MacroFake> Why is it impossible to fix this issue by limiting the range of possible values a user can enter?
10:22 < larryruane> MarcoFake: because the user can execute this RPC an unlimited number of times?
10:23 < michaelfolkson> Or is it the descendant transactions issue?
10:23 < svav> Because you don't know how many descendant transactions may be added to the mempool??
10:23 < MacroFake> Right, but why would that be an issue? (Hint: Explain what the call does internally)
10:24 < svav> MacroFake can you explain this in a bit more detail? It is impossible to predict when and if an overflow occurs, since
10:24 < svav> the overflow caused by a prioritisetransaction RPC might only be
10:24 < svav> later hit when descendant txs are added to the mempool.
10:25 < MacroFake> svav: Correct
10:25 < MacroFake> Though, there is still a second answer to the question
10:26 < MacroFake> Hint: Think about calling the rpc on the same txid
10:26 < larryruane> svav: that's really interesting (can't simply fail the RPC)
10:27 < michaelfolkson> MarcroFake: You mean calling it twice on same txid?
10:27 < larryruane> that's what your RPC repro steps do
10:27 < larryruane> (calls twice on same txid)
10:27 < larryruane> first time doesn't overflow, second time does
10:28 < larryruane> (this is what I was thinking with my earlier answer about calling the RPC an unlimited number of times)
10:28 < michaelfolkson> Change the fee by a different amount the second time? Or same fee adjustment?
10:29 < MacroFake> (For referenc we are looking at https://github.com/bitcoin/bitcoin/blob/b9122e95f0f4ff5d2b2e21a5caf6c69d488c0347/src/txmempool.cpp#L923-L939 )
10:30 < MacroFake> If there are no ancestors and no descendants, it will simply call UpdateFeeDelta on the tx itself: https://github.com/bitcoin/bitcoin/blob/b9122e95f0f4ff5d2b2e21a5caf6c69d488c0347/src/txmempool.cpp#L92-L97
10:32 < MacroFake> nModFeesWithDescendants would then be equal to nModFeesWithAncestors  and both may overflow if the applied fee delta is too high
10:32 < svav> Can someone tell me what the overflow is occurring in? What variable or whatever?
10:32 < MacroFake> michaelfolkson: Any fee delta that would result in an overflow should wok
10:32 < MacroFake> *work
10:32 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed]
10:33 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
10:34 < MacroFake> svav: The overflow may happen for any variable that tracks the modified fee.
10:34 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Client Quit]
10:34 < MacroFake> For example, it may happen for the CAmount in mapDeltas[hash] , see https://github.com/bitcoin/bitcoin/blob/b9122e95f0f4ff5d2b2e21a5caf6c69d488c0347/src/txmempool.cpp#L920
10:34 < svav> Is the problem essentially that you don't know how many times the fee delta will be applied?? If it's applied too many times it can cause an overflow??
10:35 < MacroFake> svav: You know that the fee delta will be applied to all ancestors and all descendants (even if they will be added to the mempool later)
10:36 < michaelfolkson> svav: It's not too many times. It is a value not fitting within the integer width (notes of the PR review club)
10:36 < larryruane> ah so one of those ancestors or descendants could have a large actual fee ... so for that tx, the modified fee could overflow
10:36 < svav> MarcoFalke why are you called MacroFake today? :)
10:37 < MacroFake> svav: I changed my IRC nick
10:38 < MacroFake> larryruane: Right
10:39 < michaelfolkson> When you say "leave it up to the user to use the RPC endpoint responsibly" you essentially mean don't introduce the fee by something ludicrous?
10:39 < MacroFake> michaelfolkson: Yes
10:40 < MacroFake> However, this may also be hit when reading the mempool.dat from disk
10:40 < michaelfolkson> *increase the fee (correction)
10:40 < michaelfolkson> Ok thanks
10:40 < MacroFake> Next q: Enumerate the different approaches that were discussed in the pull request and summarize each in one sentence. See abort-approach, return-early-approach, saturating-approach.
10:40 < MacroFake> abort-approach: https://github.com/bitcoin/bitcoin/pull/23418#discussion_r742736167
10:41 < MacroFake> return-early-approach: https://github.com/bitcoin/bitcoin/commit/e8522d082e5b7ab421e62c8e76fabbea24531a8d#diff-c065d4cd2398ad0dbcef393c5dfc53f465bf44723348892395fffd2fb3bac522R37
10:41 < MacroFake> saturating-approach: https://github.com/bitcoin/bitcoin/pull/23418#discussion_r744953272
10:42 < larryruane> easy part, I'm pretty sure we're taking the last one (saturating)
10:43 < michaelfolkson> Yeah not the abort approach
10:43 < larryruane> abort approach is just to violate an assert and crash the node ... but (ideally) any user input shouldn't be able to crash the node
10:43 < MacroFake> Can someone summarize each one, so that everyone is on the same page, please :)
10:43 < larryruane> return-early is where we just don't do the increment at all if it would overflow (so the result could be significantly off)
10:44 < larryruane> saturating approach means make the result as close as we can
10:44 < michaelfolkson> And abort is abort the program if the overflow occurs
10:44 < larryruane> i agree with the saturating approach
10:44 < MacroFake> larryruane: thx
10:44 < MacroFake> larryruane: Yes, user inputs shouldn't crash the program. That is a good rule of thumb.
10:45 < larryruane> (even if it is RPC, which is sort of the user shooting himself in the foot ... input from P2P would be much worse!)
10:46 < michaelfolkson> And this saturating approach still doesn't put any restrictions on what the fuzzers can do. They can go wild
10:46 < MacroFake> Well, it still requires a call to the RPC with a large/small value. But the crash could (in theory) be triggered by a P2P tx.
10:46 < afmencken> One additional approach that I didn't see mentioned would be to have the RPC return an error code. Is that a non-starter for some obvious reason that I'm not seeing?
10:46 < larryruane> MacroFake: +1 good point
10:47 < svav> Did we do Q4? Why is it impossible to fix this issue by limiting the range of possible values a user can enter?
10:47 < MacroFake> afmencken: Good question. The thing is that it is not possible to determine whether an overflow will (eventually) occur, as the overflow may happen after the RPC finished sucessfully.
10:47 < larryruane> afmencken: It doesn't solve the problem, because a tx could be added later (via P2P) that causes the overflow
10:48 < afmencken> MacroFake: larryruane: thanks, that makes sense.
10:49 < Amirreza> yeah, can someone explain why it can't be solved by limiting the range of possible inputs?
10:49 < svav> Q4?
10:49 < MacroFake> To recap Q4: Limiting the range is not sufficient. For example, you can prioritise by +1 in a loop on the same txid. This will eventually overflow.
10:49 -!- sam81 [~sam@ch-va-93622ff000-405632-1.tingfiber.com] has quit [Quit: Connection closed]
10:50 < larryruane> by the way, it's interesting how the prioritisation map can contain txids that don't exist yet in the mempool! maybe they just haven't arrived yet!
10:50 < svav> MacroFake could you try and give a few sentences on how this bug appears, because I still don't understand it fully.
10:50 < Amirreza> MacroFake: Can't we limit the number of attempt to prioritise a tx? I know it's not a good solution, but in theory, does this solve?
10:51 < michaelfolkson> Amirreza: The problem isn't the number of attempts. A single "attempt" can cause the integer overflow
10:52 < michaelfolkson> So no limiting the number of times you can change the priorisation of the tx doesn't solve it
10:52 < svav> I get that someone could set a massive fee delta and that would overflow ... but what else causes it?
10:53 < MacroFake> Amirreza: Good question. I think it would be another possible solution. However, you'd need to limit both the allowed range (based on maximum allowed ancestors/descendants), and the number of allowed calls.
10:53 < Amirreza> michaelfolkson: MacroFake: I got it, thanks.
10:53 < MacroFake> Amirreza: While this is a theoretical solution, it would be harder to implement, as it requires tracking state
10:54 < Amirreza> MacroFake: Yeah I agree
10:54 < larryruane> Also just to be clear, it's not like we're worried that this could actually happen in practice, right? It's more that we have the fuzzers and sanitizers, and we want them to run cleanly as much as possible, without having to declare exceptions (the ubsan file that this PR removes a line from)
10:55 < MacroFake> It might have happened in practise (no one knows), but I don't expect it to happen regurlarly.
10:55 < MacroFake> last q: Which approach was picked in the pull request? Do you agree that the discarded approaches are inferior?
10:57 < larryruane> MacroFake: (saturation, I agree!) If it wouldn't take too long to explain, why is signed integer overflow considered undefinied behavior? Especially while unsigned is not?
10:59 < MacroFake> unsigned integer overflow is used commonly to implement low level cryptographic primitives. I think this wouldn't be possible if the language didn't have unsigned integer overflow
10:59 < MacroFake> not sure why signed integer overflow is UB, but it usually seems unwanted if the program can run into it.
11:00 < larryruane> thanks makes sense
11:00 < MacroFake> #endmeeting
11:00 -!- yashraj [~yashraj@2607:fea8:8602:500:5992:1813:f818:b5af] has quit []
11:01 < larryruane> thanks, MacroFake and everyone else!
11:01 < MacroFake> Thanks everyone for attending. This one was a really tough one, even though the integer overflow itself is easy to understand.
11:01 < michaelfolkson> Thanks MacroFake!
11:01 < paul_c> Thanks guys
11:01 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Ping timeout (120 seconds)]
11:02 < Amirreza> Thanks everyone
11:02 < afmencken> Thanks MacroFake
11:02 < Amirreza> and MacroFake 
11:02 -!- paul_c [~paul_c@pool-74-96-221-100.washdc.fios.verizon.net] has quit [Quit: Connection closed]
11:03 -!- dpr54 [~dpr54@154.0.128.44] has quit [Quit: Connection closed]
11:03 -!- tru3nrg [~tru3nrg@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Ping timeout (120 seconds)]
11:06 < effexzi> Thanks every1 
11:10 < larryruane> does CI run the fuzz tests with the UB sanitizers enabled?
11:13 < MacroFake> yes
11:14 < MacroFake> See https://github.com/bitcoin/bitcoin/blob/b9122e95f0f4ff5d2b2e21a5caf6c69d488c0347/ci/test/00_setup_env_native_fuzz.sh#L17
11:15 < larryruane> thanks.. I just want to confirm, if a PR's fuzzing part of its CI run fails, it might have nothing to do with the PR, it was just unlucky?
11:22 < MacroFake> The fuzz CI should never fail, unless it is a timeout of some sort?
11:22 -!- sanya [~sanya@109-93-70-113.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
11:23 -!- amirreza79 [~Amirreza7@2.177.90.125] has joined #bitcoin-core-pr-reviews
11:26 -!- Amirreza [~Amirreza7@89.219.86.232] has quit [Ping timeout: 248 seconds]
11:32 -!- Amirreza [~Amirreza7@89.219.107.238] has joined #bitcoin-core-pr-reviews
11:32 -!- amirreza79 [~Amirreza7@2.177.90.125] has quit [Ping timeout: 268 seconds]
11:53 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
12:01 -!- Amirreza [~Amirreza7@89.219.107.238] has quit [Quit: Leaving]
12:13 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:45 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
12:51 < larryruane> I was just thinking that it `src/test/fuzz/fuzz` chooses a random seed when it starts, for example `INFO: Seed: 1732649896` so it might happen to stumble on a seed that uncovers a problem (test fails, CI fails) that's very unlikely and therefore almost never occurs
12:51 < larryruane> So I was just wondering if that failure is super rare, it might fail for a PR even though the PR didn't cause the failure
12:51 < larryruane> s/it/if/
13:16 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Ping timeout (120 seconds)]
13:29 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
16:21 -!- in3rsha [~in3rsha@188.30.109.99.threembb.co.uk] has joined #bitcoin-core-pr-reviews
17:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:6c60:221:1d06:2e1] has quit [Remote host closed the connection]
17:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
17:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
17:15 -!- afmencken [~afmencken@192.252.212.38] has quit [Quit: Leaving]
17:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
17:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 264 seconds]
17:22 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
17:24 -!- afmencken [~afmencken@192.252.212.38] has joined #bitcoin-core-pr-reviews
17:27 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 264 seconds]
17:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
17:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 264 seconds]
17:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
17:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
17:43 < lightlike> larryruane: I don't think that this seed is used for fuzzing in the CI runs. The CI only runs those seeds that are saved in the qa-asset repository without doing any actual fuzzing with random number, so it should be completely deterministic. New fuzz fails are found by someone doing actual fuzzing (google fuzz or at home), the CI would only find regressions caused by some change in an individual PR that affects existing saved 
17:43 < lightlike> seeds.
17:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
17:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
17:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
18:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
18:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
18:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
18:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
18:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 264 seconds]
18:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
18:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
18:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
18:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
18:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
18:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
19:05 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
19:10 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 248 seconds]
19:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
19:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 244 seconds]
19:38 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
19:42 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 246 seconds]
19:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
19:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
20:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
20:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
20:06 -!- greypw254600 [~greypw254@grey.pw] has quit [Remote host closed the connection]
20:06 -!- greypw254600 [~greypw254@grey.pw] has joined #bitcoin-core-pr-reviews
20:07 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
20:16 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 264 seconds]
20:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
20:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 244 seconds]
20:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
20:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 244 seconds]
20:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
20:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 248 seconds]
20:56 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
21:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 248 seconds]
21:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
21:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
21:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
21:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 264 seconds]
21:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
22:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 272 seconds]
22:11 -!- dongcarl [~dongcarl@pool-108-6-233-95.nycmny.fios.verizon.net] has quit [Quit: Ping timeout (120 seconds)]
22:11 -!- dongcarl [~dongcarl@pool-108-6-233-95.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
22:16 -!- dongcarl [~dongcarl@pool-108-6-233-95.nycmny.fios.verizon.net] has quit [Quit: Ping timeout (120 seconds)]
22:19 -!- dongcarl [~dongcarl@pool-108-6-233-95.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
22:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
22:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
22:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
22:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 272 seconds]
22:37 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
22:42 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 272 seconds]
22:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
22:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 272 seconds]
22:53 -!- dongcarl [~dongcarl@pool-108-6-233-95.nycmny.fios.verizon.net] has quit [Ping timeout: 272 seconds]
22:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
22:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
22:58 -!- dongcarl [~dongcarl@pool-108-6-233-95.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
22:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
23:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 272 seconds]
23:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
23:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
23:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
23:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
23:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
23:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 240 seconds]
23:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
23:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 268 seconds]
23:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has joined #bitcoin-core-pr-reviews
23:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9cf9:e950:a794:5a74] has quit [Ping timeout: 264 seconds]
--- Log closed Thu Jun 23 00:00:00 2022