--- Log opened Fri Jun 04 00:00:28 2021 00:10 -!- Kiminuo [~Kiminuo@141.98.103.92] has quit [Ping timeout: 264 seconds] 00:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:30 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #22146: Reject invalid coin height and output index when loading assumeutxo (master...2106-auHeight) https://github.com/bitcoin/bitcoin/pull/22146 00:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:41 -!- evias [~evias__@196.red-88-6-131.staticip.rima-tde.net] has joined #bitcoin-core-dev 00:41 -!- evias [~evias__@196.red-88-6-131.staticip.rima-tde.net] has quit [Changing host] 00:41 -!- evias [~evias__@user/evias] has joined #bitcoin-core-dev 00:48 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f03bc00ce1eb7ce7a269f20.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 00:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:52 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c7dd9ff71b9c...a748782a11f0 00:52 < bitcoin-git> bitcoin/master 3d552b0 Sjors Provoost: [doc] explain why CheckBlock() is called before AcceptBlock() 00:52 < bitcoin-git> bitcoin/master a748782 MarcoFalke: Merge bitcoin/bitcoin#15545: [doc] explain why CheckBlock() is called befo... 00:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 00:52 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15545: [doc] explain why CheckBlock() is called before AcceptBlock (master...2019/03/clarify-checkblock) https://github.com/bitcoin/bitcoin/pull/15545 00:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 00:57 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 01:04 < vasild> michaelfolkson: for me the meetings' time of the day is a showstopper 01:06 < michaelfolkson> vasild: Without doxing your specific location are you Asia Pacific timezone? 01:06 < vasild> michaelfolkson: I am in Central Europe (GMT+2) 01:07 < michaelfolkson> Oh ok, just other commitments in evenings? I am GMT+1 and timings are fine for me 01:07 < vasild> family time, dinner, sleep early :) 01:08 < michaelfolkson> Fair enough :) 01:08 < michaelfolkson> I feel bad for Asia Pacific people, often in the middle of the night for them 01:08 < vasild> yeah, that's even worse 01:11 < vasild> jnewbery: wrt running the fuzzer in CI, I did not follow the discussion closely, was something decided about it? It occurred to me that it makes sense to run the fuzzer on CI on every pull request using the pre-generated seeds if that increases the code coverage. E.g. if without the fuzzer a CI run gets 80% coverage of a pull and if with the fuzzer that gets to e.g. 85% then it makes sense to run 01:12 < vasild> it on every pull 01:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 01:13 < bitcoin-git> [bitcoin] MarcoFalke pushed 1 commit to 0.20: https://github.com/bitcoin/bitcoin/compare/8b5c83b4aa8c...5d2ebdd2b71f 01:13 < bitcoin-git> bitcoin/0.20 5d2ebdd W. J. van der Laan: build: Bump version to 0.20.2rc2 01:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 01:13 < MarcoFalke> laanwj: sipa: hebasto: Fixed by typing "git push bitcoin-core 5d2ebdd2b71fadfcbadc32d074c83e1ff92043b5:0.20" 01:14 < MarcoFalke> At least that fixed it for me: " * [new tag] v0.20.2rc2 -> v0.20.2rc2" 01:15 < MarcoFalke> vasild: I'd be a hard NACK removing the fuzz tests. Might as well remove all other tests 01:16 < vasild> I agree, but this was discussed in a meeting recently, IIRC due to some sporadic timeouts 01:16 < _aj_> MarcoFalke: once #21496 is done, could run against the existing fuzz corpus without actually compiling for fuzzing -- could see that being worth a try 01:16 <@gribble> https://github.com/bitcoin/bitcoin/issues/21496 | fuzz: execute each file in dir without fuzz engine by AnthonyRonning · Pull Request #21496 · bitcoin/bitcoin · GitHub 01:18 < vasild> some problems in my pulls were discovered only by the fuzz+some-sanitizer CI 01:59 < laanwj> MarcoFalke: thanks for fixing it, i was wondering what went wrong 02:09 < michaelfolkson> vasild: I saw you added to P2P current priorities "Add some basic docs/howto at doc/i2p.md, similarly to doc/tor.md" 02:10 < michaelfolkson> vasild: Feel free to use any of this SE post https://bitcoin.stackexchange.com/questions/103402/how-can-i-use-bitcoin-core-with-the-anonymous-network-protocol-i2p 02:11 < michaelfolkson> vasild: I quite like the idea of using StackExchange as a staging ground or place for drafts before they are ready to add to Core docs :) 02:11 < jonatack> michaelfolkson: there is a wide range of area within the CET timezone (maybe other timezones too but CET I know well), e.g. sun setting and rising much "earlier" in the eastern parts 02:11 < vasild> michaelfolkson: thanks for the link, I should do that before 22.0 release 02:18 -!- Conor [uid501933@id-501933.charlton.irccloud.com] has quit [Quit: Connection closed for inactivity] 04:15 -!- tutwidi[m] [~tutwidima@2001:470:69fc:105::ead] has joined #bitcoin-core-dev 04:29 -!- thedragon [~thedragon@user/thedragon] has joined #bitcoin-core-dev 04:36 -!- thedragon [~thedragon@user/thedragon] has quit [Quit: Leaving] 04:54 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 272 seconds] 04:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:56 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a748782a11f0...3ac5209662ce 04:56 < bitcoin-git> bitcoin/master e4356f6 Daniel Kraft: Testcase for wallet issue with orphaned rewards. 04:56 < bitcoin-git> bitcoin/master 3ac5209 MarcoFalke: Merge bitcoin/bitcoin#18795: Test: wallet issue with orphaned rewards 04:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:56 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #18795: Test: wallet issue with orphaned rewards (master...orphanedreward-test) https://github.com/bitcoin/bitcoin/pull/18795 04:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:56 -!- ksprd3 [~ksprd@212.14.60.132] has joined #bitcoin-core-dev 05:04 -!- thedragon [~thedragon@user/thedragon] has joined #bitcoin-core-dev 05:08 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 05:32 < jnewbery> MarcoFalke: saying "we might as well remove all other tests" is not helpful. The point is that we've loaded so many additional tasks onto the CI that it gives frequent false failures. 05:33 < jnewbery> If developers first thought when seeing a failing CI is "it's probably a spurious failure, I'll hit re-run", then it's worse than useless. 05:34 < jnewbery> and the approach of "let's just spend money and throw more CPU at the problem" isn't a good solution 05:34 < hebasto> it appears that `lupdate` can produce XLIFF file directly; the drawback is that `-locations relative` does not work in this case 05:35 < hebasto> laanwj: luke-jr: ^ 05:38 -!- goatpig [~goat@blocksettle-gw.cust.31173.se] has quit [Quit: Konversation terminated!] 05:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 05:40 < bitcoin-git> [bitcoin] sdaftuar opened pull request #22147: p2p: Protect last outbound HB compact block peer (master...2021-06-reserve-outbound-hb) https://github.com/bitcoin/bitcoin/pull/22147 05:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 05:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 05:43 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3ac5209662ce...346e52afd6d5 05:43 < bitcoin-git> bitcoin/master fa4245d MarcoFalke: doc: Various validation doc fixups 05:43 < bitcoin-git> bitcoin/master 346e52a fanquake: Merge bitcoin/bitcoin#22121: doc: Various validation doc fixups 05:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 05:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 05:43 < bitcoin-git> [bitcoin] fanquake merged pull request #22121: doc: Various validation doc fixups (master...2106-docVal) https://github.com/bitcoin/bitcoin/pull/22121 05:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 05:49 -!- sagi [~sagi@bzq-79-178-136-188.red.bezeqint.net] has quit [Ping timeout: 272 seconds] 06:02 -!- kabaum [~kabaum@h-46-59-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 265 seconds] 06:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:06 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #22149: test: Add temporary logging to debug #20975 (master...2106-testDebug) https://github.com/bitcoin/bitcoin/pull/22149 06:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:07 -!- bomb-on [~bomb-on@194.144.47.113] has joined #bitcoin-core-dev 06:20 < MarcoFalke> jnewbery: Sure but then the first attempt should be to fix the spurious failure, not to remove the whole test config 06:22 < MarcoFalke> Without any way to run the fuzz tests in CI, they will quickly become stale 06:23 < MarcoFalke> We've already moved the fuzz memory sanitizers out of the ci config. The memory issues are rare enough that they can be fixed up after a merge 06:24 < MarcoFalke> Though the other issues (logic bugs in the fuzz code, other sanitizer issues, ...) are far more frequent and need to be dealt with in the pull that introduces the issue 06:26 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 272 seconds] 06:27 < MarcoFalke> If there is a specific fuzz test that is slow and not too helpful, we could remove that one 06:29 < MarcoFalke> Also, we have plenty of intermittent failures in the functional test suite, which are waiting to be fixed 06:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:37 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #22150: test: Remove unused node from feature_nulldummy (master...2106-testFaster) https://github.com/bitcoin/bitcoin/pull/22150 06:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:42 -!- sagi [~sagi@bzq-79-178-136-188.red.bezeqint.net] has joined #bitcoin-core-dev 06:47 -!- ksprd3 [~ksprd@212.14.60.132] has quit [Ping timeout: 245 seconds] 07:06 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Remote host closed the connection] 07:06 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 07:13 -!- ksprd3 [~ksprd@212.14.60.132] has joined #bitcoin-core-dev 07:44 -!- davterra [~davterra@178.128.106.205] has joined #bitcoin-core-dev 07:49 -!- TheCharlatan [~drgrid@2a01:4f9:4a:2adc::2] has joined #bitcoin-core-dev 07:58 -!- ksprd3 [~ksprd@212.14.60.132] has quit [Quit: WeeChat 3.1] 07:59 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-dev 08:36 -!- jarthur [~jarthur@2603-8080-1540-002d-c1fc-d572-2f65-fc99.res6.spectrum.com] has joined #bitcoin-core-dev 08:39 -!- copumpkin [~woohoo@user/copumpkin] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:39 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 08:40 -!- copumpkin [~woohoo@user/copumpkin] has quit [Client Quit] 08:40 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 08:40 -!- copumpkin [~woohoo@user/copumpkin] has quit [Client Quit] 08:41 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 08:41 -!- copumpkin [~woohoo@user/copumpkin] has quit [Client Quit] 08:42 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 08:42 -!- copumpkin [~woohoo@user/copumpkin] has quit [Client Quit] 08:43 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 08:43 -!- copumpkin [~woohoo@user/copumpkin] has quit [Client Quit] 08:43 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 08:44 -!- copumpkin [~woohoo@user/copumpkin] has quit [Client Quit] 08:44 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 08:44 -!- copumpkin [~woohoo@user/copumpkin] has quit [Client Quit] 08:45 -!- lkqwejhhgasdjhgn [~kljkljklk@p200300d46f03bc00ce1eb7ce7a269f20.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] 09:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:18 < bitcoin-git> [bitcoin] hebasto opened pull request #22151: build: Follow Transifex docs to prepare XLIFF source (master...210604-xliff) https://github.com/bitcoin/bitcoin/pull/22151 09:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:36 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has quit [Quit: node-irc says goodbye] 09:36 -!- orionwl[m] [~orionwlx0@2001:470:69fc:105::80] has quit [Quit: node-irc says goodbye] 09:36 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Quit: node-irc says goodbye] 09:36 -!- kvaciral[m] [~kvaciralx@2001:470:69fc:105::17b] has quit [Quit: node-irc says goodbye] 09:36 -!- dongcarl[m] [~dongcarlm@2001:470:69fc:105::82] has quit [Quit: node-irc says goodbye] 09:36 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has quit [Quit: node-irc says goodbye] 09:36 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Quit: node-irc says goodbye] 09:36 -!- tutwidi[m] [~tutwidima@2001:470:69fc:105::ead] has quit [Quit: node-irc says goodbye] 09:37 -!- orionwl[m] [~orionwlx0@2001:470:69fc:105::80] has joined #bitcoin-core-dev 09:40 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #bitcoin-core-dev 09:40 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #bitcoin-core-dev 09:40 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has joined #bitcoin-core-dev 09:40 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has joined #bitcoin-core-dev 09:40 -!- dongcarl[m] [~dongcarlm@2001:470:69fc:105::82] has joined #bitcoin-core-dev 09:40 -!- kvaciral[m] [~kvaciralx@2001:470:69fc:105::17b] has joined #bitcoin-core-dev 09:40 -!- tutwidi[m] [~tutwidima@2001:470:69fc:105::ead] has joined #bitcoin-core-dev 09:46 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev 09:47 < ryanofsky> A compromise short of disabling unreliable tests, could be adding a way to mark them flaky. Flaky tests would still run but just collect debug info and not cause the CI to fail 09:47 < ryanofsky> This would also let us track which tests are unreliable over time 09:49 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Quit: node-irc says goodbye] 09:50 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #bitcoin-core-dev 09:50 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 265 seconds] 09:50 -!- lukedashjr is now known as luke-jr 09:50 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 244 seconds] 09:51 < luke-jr> hebasto: can we postprocess to remove the locations entirely? (do they serve a purpose?) 09:52 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 09:53 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev 10:00 -!- jonatack [jonatack@user/jonatack] has joined #bitcoin-core-dev 10:07 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev 10:09 -!- copumpkin [~woohoo@user/copumpkin] has joined #bitcoin-core-dev 10:10 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 264 seconds] 10:10 -!- lukedashjr is now known as luke-jr 10:11 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 10:13 < hebasto> luke-jr: do you mean for the source file? 10:13 < hebasto> probably locations are used by Qt Linguist 10:14 < hebasto> but not sure 11:04 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Remote host closed the connection] 11:05 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 11:08 < achow101> #proposedwalletmeetingtopic subtract fee from recipients intended behavior and edge cases 11:10 -!- earnestly [~earnest@user/earnestly] has joined #bitcoin-core-dev 11:13 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 245 seconds] 11:13 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev 11:24 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has joined #bitcoin-core-dev 11:40 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has quit [Ping timeout: 244 seconds] 12:00 < achow101> #startmeeting 12:00 < core-meetingbot> Meeting started Fri Jun 4 19:00:37 2021 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings. 12:00 < core-meetingbot> Available commands: action commands idea info link nick 12:00 < sipa> hi 12:00 < jonatack> hi 12:01 < achow101> #bitcoin-core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd 12:01 < achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild 12:01 < achow101> I have a topic, but are there any other topics for today? 12:01 < sipa> topic suggestion: what to prioritize for taproot wallet support? there are probably half a dozen things that need to be done 12:01 < michaelfolkson> hi 12:02 < jarolrod> hi 12:02 < fjahr> hi 12:02 < achow101> #topic subtract fee from recipients intended behavior and edge cases (achow101) 12:02 < core-meetingbot> topic: subtract fee from recipients intended behavior and edge cases (achow101) 12:03 < achow101> What is the exact behavior and use case we expect for the subtract fee from recipients feature? 12:03 < sipa> can you give an example of where the expected behavior isn't clear? 12:03 < ryanofsky> (context is https://github.com/bitcoin/bitcoin/pull/22008#pullrequestreview-676528963) 12:03 < achow101> ryanofsky noticed that the current implementation (after 17331 removed the loop) will increase the recipient amounts if a dropped change output was more than the required fee 12:04 < achow101> I looked at the previous looping implementation, and it looks like that would actually just overpay the fees in that case. it would reduce the fee from the recipients, then drop the change output to fee 12:04 < achow101> I think neither of these things are what we want to do 12:05 < michaelfolkson> Your view is... achow101? :) 12:05 < sipa> what does dropped mean here? don't you "start" from a transaction without change, and add it if necessary? 12:06 < achow101> michaelfolkson: https://github.com/bitcoin/bitcoin/pull/22008#issuecomment-854880614 12:06 < jonatack> sipa: was wondering this too 12:06 < achow101> sipa: we start from a transaction with change, then subtract the fees from it. then if it is below dust or the exact match window, we remove the change output 12:06 < achow101> with subtract fee from output, we skip the "subtract fees from it" step 12:07 < sipa> achow101: only in the current knapsack? 12:07 < achow101> sipa: always 12:07 < achow101> we do this regardless of the algorithm 12:07 < achow101> with BnB, the change always ends up in the exact match window since we do the same math, so the change is always dropped 12:08 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 264 seconds] 12:08 < ryanofsky> IMO the choice is just between slightly overpaying fees and being pedantic about the word "subtract". Or just keeping current behavior and mostly subtracting sometimes adding to recipient when it's most efficient 12:09 < ryanofsky> This is good for the use-case of transferring funds between wallets, which is at least is where I've used subtract from recipient before 12:09 < michaelfolkson> I do think paying a little more than the recipient is expecting is strange behavior for both the sender and the receiver 12:09 < ryanofsky> It deserves to be documented, sure 12:09 < achow101> what we've always done is overpay fees, probably too much 12:09 < sipa> ryanofsky: i think that's the most important use case 12:09 < sipa> moving all funds from one wallet to another 12:09 < ryanofsky> But I think you choose behavior based on use cases, not on being pedantic about terminology 12:10 < achow101> ryanofsky: the use case I've seen the most is moving all funds from one wallet to another, in which case this discussion doesn't matter 12:10 < achow101> but we don't really know what people actually use this for 12:10 < ryanofsky> achow101, it matters because in one case you overpay the miner, in the other case you have a little more funds in your new wallet 12:11 -!- Guest37 [~Guest37@116.68.83.230] has joined #bitcoin-core-dev 12:11 < sipa> is this a long term problem? i'd imagine that in a BnB + SRD world, you have two algorithms one that aims for no-change solutions, and one that aims for with-change solutions, and you pick the best one 12:11 < ryanofsky> but it doesn't matter that much, it is always a case where amount is less than the estimated cost of creating & spending the utxo 12:12 < Guest37> Im looking for a developer, anyone freelancing? 12:12 < sipa> and if the with-change solution results in too low change, you just discard that solution 12:12 < michaelfolkson> Guest37: Sorry, in the middle of a meeting 12:12 < sipa> or you convert it to a no-change one, and consider it in that form 12:13 < jonatack> use case: i subtractfeefromamount in the case of say, selling btc to a party who chooses the fee rate they want to use for the txn 12:13 < Guest37> its okay, after call me.paying big bucks for a bitcoin competitor. "Bitcoin Green" - Runs 100% sustainable. No electricity used ever. 12:13 < sipa> Guest37: go away 12:13 < Guest37> PM me before u miss the launch 12:13 < ryanofsky> sipa, this is all after coin selection, when the algorithm has already run and then we discover the change output is uneconomical 12:13 < Guest37> *scoff* nerds 12:13 < achow101> I think this case is an extreme edge case 12:13 < ryanofsky> so we discard the change output, and pay slightly more fees in the normal case 12:13 < achow101> especially after effective value 12:14 < ryanofsky> and in the subtract from recipients case we can do a little better and send the extra amount to recipients, which is what the code is doing now 12:14 -!- Guest37 [~Guest37@116.68.83.230] has quit [Client Quit] 12:14 < ryanofsky> but agree it is not very important 12:14 < sipa> ryanofsky: which means it increases the waste metric (once that's in use), and will hopefully not be favored if an actual no-change solutions exists too 12:15 < sipa> ? 12:15 < ryanofsky> Not sure, I'm not familiar with the waste metric yet 12:15 < achow101> sipa: I don't think the waste metric accounts for change being dust, yet 12:16 < sipa> it should, i think 12:16 < sipa> overpaying fee is waste 12:16 < achow101> right, we do consider that when we know there is no change 12:17 < achow101> actually, thinking on it, I don't think knapsack can even find a solution where change would be dust. 12:17 < achow101> since it targets a minimum change value 12:18 < ryanofsky> Then maybe it is even more rare and only happens with manual coin selection 12:18 < sipa> i'm thinking something similar 12:19 < achow101> indeed 12:19 < jonatack> test coverage on this may be nice, if missing 12:19 < sipa> in whatever situation where you'd end up with change that's uneconomical (which dust definitely is), there *should* exist a better no-change solution that BnB would find 12:20 < sipa> at the very least, the one that's exactly the same but with the change converged to fee 12:20 < sipa> (but possibly, a better one too) 12:20 -!- gwillen [~gwillen@user/gwillen] has joined #bitcoin-core-dev 12:20 < ryanofsky> Either way, I'm just defending current behavior, and don't see a benefit in changing besides being more strict about "subtract". But I don't think it would be a huge deal to change 12:21 < achow101> ryanofsky: the current behavior is accidental though, and if you look at before 17331, we would always overpay 12:21 < ryanofsky> Ok, I did write the code intentionally that way when I suggested in in the other PR, but maybe I misread previous behavior 12:22 < achow101> I didn't realize that at that time. if I did, we would have had this discussion several weeks ago 12:22 < ryanofsky> I was trying not to change behavior, but I think I was basing it on your existing changes in that PR not the previous code. 12:23 < ryanofsky> Anyway, that would be another reason to change, which is fine 12:24 < achow101> I'll do some further analysis on the actual conditions this could occur and we can revisit this later 12:24 < achow101> as usual, coin selection remains inscrutable 12:25 < achow101> #topic what to prioritize for taproot wallet support? (sipa) 12:25 < core-meetingbot> topic: what to prioritize for taproot wallet support? (sipa) 12:25 < ryanofsky> Sure, and you should really do what you want there ultimately 12:26 < michaelfolkson> Can you give an update on where we are with Taproot wallet support to start with sipa? I saw this PR though haven't looked through it yet https://github.com/bitcoin/bitcoin/pull/21365 12:26 < sipa> so a rough list of missing things in master: signing support, descriptor inference support, multisig support (multi(k,...) doesn't exist in taproot), actual PSBT support with extensions so spending paths can be conveyed, support for easily constructing no-keypath descriptors, ... 12:27 < sipa> do we want to try to get signing support in 22.0? 12:27 < achow101> I think we should try to get signing support for 22.0 12:27 < achow101> and basic descriptor inference 12:27 < fjahr> hell yeah :) 12:28 < sipa> signing for basic stuff is done (which is really only useful for keypath signing, but in theory does script paths too) 12:28 < achow101> michaelfolkson: we have tr() descriptor construction with keys only now. you can import them into a watch only descriptor wallet 12:28 < sipa> so we punt multisig support and other descriptor extensions 12:29 < sipa> and just try to get basic key path signing to work 12:29 < achow101> I think that's reasonable 12:29 < achow101> also 22.0 should be released before taproot activates, so I don't think we need to have support for everything at the very beginning 12:29 < sipa> we'll want PSBT extensions for taproot (and musig, once that's a bit further along), but that's a larger discussion than just the bitcoin core wallet 12:30 < michaelfolkson> So that would just be #21365 that needs review and merging for 22.0? 12:30 <@gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub 12:30 < sipa> plus inference support 12:31 < achow101> basic inference support shouldn't be particularly hard 12:31 < achow101> do we need to add OutputType::BECH32M? 12:32 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 12:32 < sipa> that's a good question 12:32 < sipa> i'd say yes 12:32 < sipa> because it's something receivers care about 12:32 < achow101> agreed 12:32 < achow101> that also shouldn't be hard 12:33 < sipa> indeed 12:33 < sipa> i don't know much about the interaction with descriptor wallets, but i can try 12:33 < achow101> I can look at it 12:33 < achow101> I don't think it requires much in the wallet itself 12:34 < michaelfolkson> Inference support is just docs, error messages, things like that? 12:34 < sipa> lots of RPCs report inferred descriptors 12:34 < achow101> michaelfolkson: inference support is getting the descriptor for a given scriptPubKey 12:35 < michaelfolkson> Oh ok, thanks 12:35 < achow101> reminder that feature freeze is in ~10 days 12:36 < achow101> anything else to discuss? 12:37 < sipa> GetDestinationForKey... doesn't need BECH32M support, right? 12:37 < sipa> that's only for legacy wallets i assume (and hope) 12:38 < achow101> sipa: should be for legacy wallets only 12:38 < achow101> so no 12:38 < sipa> dumpwallet is disabled for descriptor wallets? 12:38 < achow101> yes 12:39 < achow101> #endmeeting 12:39 < core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt 12:39 < core-meetingbot> Meeting ended Fri Jun 4 19:39:35 2021 UTC. 12:39 < core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-06-04-19.00.moin.txt 12:40 < michaelfolkson> Did you ever consider doing a wallet current priorities page? Like the P2P one on the dev wiki? https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities 12:41 < michaelfolkson> When people update it it makes it easier to follow what people are working on wallet related 12:41 < achow101> we could add one 12:42 < michaelfolkson> Sounds like Taproot support is the current priority generally for the wallet 12:42 < warren> BTW did anyone announce the move of #bitcoin-core-dev to Libera? Libera had retweeted those announcements for other projects. 12:44 < michaelfolkson> warren: It was announced in some places, there are always going to be more places it could be announced in. You want a tweet specifically from say a Bitcoin Core Twitter account? 12:44 < sipa> laanwj: want to tweet about the IRC move from bitcoincoreorg? 12:45 < laanwj> sure 12:46 < laanwj> no problem with that, though i generally don't tweet IRC related things, definitely not on the bitcoincoreorg account, it seems more developer-internal than announcement 12:46 < ryanofsky> Wow, I thought the whole reason we used IRC was so no one would find us. Maybe this tweeting thing will turn over a new leaf :) 12:46 < sipa> laanwj: that's fair 12:46 < laanwj> ryanofsky: that 12:46 < sipa> we don't really have "user facing" stuff on IRC, maybe other projects do 12:47 < warren> that's a good point, I guess it matters for the other channels not this 12:47 < achow101> I do remember seeing (and tweeting) a few wtf tweets when freenode closed the channel 12:47 < warren> but there is no "official" account to tweet for the user channels 12:47 < laanwj> if you want to make a "community channel" that's okay but it probably shouldn't be here 12:47 < warren> I retract that question. 12:47 < laanwj> at least with libera we have free well-working bridging to matrix 12:48 < laanwj> so if you want a lot of people here, just ask 12:48 < jonatack> no tweet sgtm 12:48 < warren> Is Matrix good? I hadn't heard about code quality and association with altcoin devs made me suspicious early on. 12:48 < laanwj> yes, matrix is basically discord but free software 12:49 < achow101> sipa: what about bech32m in the gui? 12:49 < sipa> achow101: we probably want that too, but i don't think it's a short term requirement 12:49 < sipa> as long as we don't intend to expose creation of taproot wallets by default 12:49 < laanwj> +e2e encryption 12:49 < laanwj> but not if you IRC bridge ofc 12:50 < achow101> sipa: I suppose right now if you can make a taproot wallet, you can also use the cli to get addresses 12:50 < sipa> right 12:51 < sipa> you'll need RPC to import the descriptor anyway 12:53 < laanwj> warren: not sure where you get the association with altcoin devs from--but in any case it's used in large scale outside cryptocurrency, for example FOSDEM 2021 was done entirely on matrix 13:01 < achow101> sipa: are you going to do both OutputType::BECH32M and infer support, or would you like me to take a look at one (or both) of them? 13:01 < sipa> i'll do inference 13:01 < achow101> ok, I'll do outputtype then 13:02 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has joined #bitcoin-core-dev 13:02 < warren> laanwj: apparently major early funding came from altcoin ecosystems. glad to hear it doesn't matter now. 13:02 < michaelfolkson> Added a wallet current priorities page/IRC meetings page on the dev wiki https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Wallet-Current-Priorities-and-IRC-meetings 13:02 < michaelfolkson> (for the wallet) 13:02 < laanwj> warren: fair enough, it's the same thing that makes me skeptical about radicle as a decentralized github at the moment 13:03 < warren> same problem with signal I guess 13:03 < michaelfolkson> I drafted an example for you sipa, hope you don't mind :) 13:04 < laanwj> i have been trying to keep track of it but really it's too much about tokens and "governance" instead of delivering useful functionality 13:04 < michaelfolkson> Please correct if inaccurate 13:04 < laanwj> yes 13:05 < sipa> who would have thought that money corrupts 13:06 < sipa> "Many solutions were suggested for this problem, but most of these were largely concerned with the movement of small green pieces of paper, which was odd because on the whole it wasn't the small green pieces of paper that were unhappy." 13:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:07 < bitcoin-git> [bitcoin] mzumsande opened pull request #22153: test: Fix p2p_leak.py intermittent failure (master...202106_fix_p2p_leak) https://github.com/bitcoin/bitcoin/pull/22153 13:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:07 < laanwj> hehe, yes it's supposed to be a motivation for people to do useful things, i'm not convinced 13:09 < michaelfolkson> Some people manage to stay just as productive post money. Admittedly some don't :) 13:11 -!- smartin [~Icedove@88.135.18.171] has quit [Quit: smartin] 13:13 -!- GIANTWORLDKEEPER [~pjetcetal@2.95.204.25] has quit [Quit: EXIT] 13:13 -!- GIANTWORLDKEEPER [~pjetcetal@2.95.204.25] has joined #bitcoin-core-dev 13:27 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev 13:29 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has quit [Ping timeout: 264 seconds] 13:29 < hebasto> observing vandal-like actions in Ukrainian translation on Transifex; made local backups just in case 13:30 < sipa> hebasto: i hope it has history, and changes can be reverted? 13:31 < hebasto> sipa: right, on per-message basis 13:34 < hebasto> I've send a message to that user asking for more attention (in case his three actions in a row were made by accident) 13:38 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has joined #bitcoin-core-dev 13:39 < hebasto> is 0.20.2rc2 supposed to be signed for windows only, or macos as well? 13:47 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has quit [Ping timeout: 268 seconds] 13:54 -!- evias [~evias__@user/evias] has quit [Quit: This computer has gone to sleep] 13:57 -!- lightlike [~lightlike@user/lightlike] has quit [Quit: Leaving] 14:08 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has joined #bitcoin-core-dev 14:23 < achow101> hebasto: it should have a macos sig too, just waiting on jonasschnelli 14:23 < hebasto> achow101: ok 14:23 < achow101> sipa: what about importing tr() descriptors and bech32m addresses into legacy wallets? I guess it would make sense to be able to watch them with a legacy wallet? 14:25 < sipa> achow101: just watching would be easy i guess, just convert them to watched scripts 14:25 < achow101> but that would also end up watching the p2sh wrapped versions too (I think) 14:25 < sipa> right 14:26 < sipa> that could be avoided with more special casing, i guess 14:26 < sipa> but also doing more (like enabling updating PSBT with that, once there are extensions) will be hard 14:26 < achow101> my thought was to just completely disallow bech32m for legacy wallets 14:26 < sipa> i think that makes sense 14:26 < achow101> which should take care of any future things too 14:37 < sipa> right 14:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:48 < bitcoin-git> [bitcoin] achow101 opened pull request #22154: Add OutputType::BECH32M and related wallet support for fetching bech32m addresses (master...outputtype-bech32m) https://github.com/bitcoin/bitcoin/pull/22154 14:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:54 -!- SenX [~textual@2600:1700:42f0:f60:c0f4:898b:4a73:14b1] has joined #bitcoin-core-dev 14:57 -!- belcher_ is now known as belcher 15:00 -!- kabaum [~kabaum@host-78-77-217-248.mobileonline.telia.com] has quit [Ping timeout: 245 seconds] 15:03 -!- OP_NOP_ [~OP_NOP@154.3.250.73] has joined #bitcoin-core-dev 15:07 -!- OP_NOP [~OP_NOP@154.29.131.8] has quit [Ping timeout: 252 seconds] 15:15 -!- Guest75 [~Guest75@host-212-171-3-157.retail.telecomitalia.it] has joined #bitcoin-core-dev 15:15 -!- Guest75 [~Guest75@host-212-171-3-157.retail.telecomitalia.it] has quit [Client Quit] 15:53 -!- nopf [~nopf@n218103136056.netvigator.com] has joined #bitcoin-core-dev 15:53 -!- nopf [~nopf@n218103136056.netvigator.com] has quit [K-Lined] 15:56 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 264 seconds] 15:58 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 16:02 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev 16:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:11 < bitcoin-git> [bitcoin] ryanofsky opened pull request #22155: wallet test: Add test for subtract fee from recipient behavior (master...pr/subfee) https://github.com/bitcoin/bitcoin/pull/22155 16:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:19 -!- SenX [~textual@2600:1700:42f0:f60:c0f4:898b:4a73:14b1] has quit [Quit: My iMac has gone to sleep. ZZZzzz…] 16:37 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has quit [Ping timeout: 268 seconds] 16:40 < sipa> achow101: this is a much harder problem than i thought 16:41 < sipa> inferring tr descriptors 16:41 < sipa> fun edge case: what if you have repeated subtrees 16:42 -!- davterra [~davterra@178.128.106.205] has quit [Read error: Connection reset by peer] 16:42 -!- davterra [~davterra@178.128.106.205] has joined #bitcoin-core-dev 16:43 < achow101> sipa: for 22.0, I think we can have just the minimum of "OP_1 " -> "tr()" 16:44 < sipa> sure 16:44 < sipa> well, that's not correct 16:44 < sipa> even single-key cases get tweaked 16:44 < sipa> but still, that wouldn't be hard to do 16:45 < achow101> but the tweak is reversible? 16:45 < sipa> no 16:45 < sipa> it's similar to P2PKH in a way 16:45 < sipa> you can't infer the pubkey from the scriptPubKey 16:46 < sipa> but if you started from an expanded descriptor, you have enough information in the SigningProvider to infer 16:48 < achow101> ah, without the internal key, you can't get the tweak 16:48 < sipa> right, the tweak is literally just H(internal key) 16:50 < achow101> but with access to the SigningProvider, it is possible to get at least the internal key 16:50 < sipa> the rest too 16:50 < sipa> it's just a bit tricky to infer a tree structure from a bunch of leaves 16:50 < achow101> how is the tree stored in the SigningProvider? 16:51 < sipa> as a map (script -> controlblock) 16:51 < sipa> which is kind of how i expect it to end up in PSBT as well 16:51 < sipa> though obviously the internal structure can change if some other approach is taken 16:52 < sipa> if the internal structure is literally the tree it'd be easier, but i think that would be hard to map to something PSBT-like I think 16:52 < sipa> unless it's a field of the form "here is the serialized tree, go nuts" 16:52 < achow101> that would be the easiest 16:52 < achow101> but perhaps not privacy preserving 16:53 < sipa> right, it'd be nice if it was possible to give "this is the only branch you need to care about" 16:53 < achow101> so the problem is if you have the same script in different parts of the tree 16:54 < sipa> oh 16:54 < sipa> lol 16:54 < sipa> this problem just cannot occur 16:54 < achow101> phew 16:54 < sipa> because to have repeated subtrees, you need repeated leaves 16:54 < sipa> and repeated leaves can't be encoded in a (script -> control) map 16:54 < sipa> it'd need to be a multimap 16:54 < achow101> I was going to point that out 16:54 < sipa> thanks! 16:55 < achow101> why couldn't we have repeated leaves? 16:55 < sipa> in descriptor form they're possible 16:56 < sipa> but not in the SigningProvider form i have now 16:56 < sipa> (they're also pointless...) 16:56 < achow101> so we could just disallow them 16:57 < sipa> yeah, though they can't be detected in descriptor form 16:57 < sipa> only after derivation 16:58 < sipa> e.g. you could have tr(KEY,{xpub/*,pubkey}), and pubkey matches the xpub/* derivation at index 1923098173981 16:59 < achow101> hmm 17:04 < achow101> it would kind of suck if you find out that you can't use an address during derivation 17:04 < sipa> indeed 17:04 < sipa> i think it's better not to forbid those 17:04 < sipa> and just find a way (eventually) to infer them 17:05 < achow101> right 18:09 -!- copumpkin [~woohoo@user/copumpkin] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 18:33 < bitcoin-git> [bitcoin] achow101 opened pull request #22156: Only allow tr() import to privkey wallets when Taproot is active (master...disallow-tr-privkey-import) https://github.com/bitcoin/bitcoin/pull/22156 18:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 18:42 -!- earnestly [~earnest@user/earnestly] has quit [Ping timeout: 245 seconds] 18:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 18:57 < bitcoin-git> [bitcoin] EthanHeilman opened pull request #22158: rng: adds support for x86 rdrand/rdseed instructions when building using MSVC (master...winx86rngcpu) https://github.com/bitcoin/bitcoin/pull/22158 18:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 19:02 -!- bomb-on [~bomb-on@194.144.47.113] has quit [Quit: aллилѹіа] 19:49 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev 21:16 -!- jarthur [~jarthur@2603-8080-1540-002d-c1fc-d572-2f65-fc99.res6.spectrum.com] has quit [Ping timeout: 244 seconds] 21:17 -!- Guest69 [~Guest69@24.136.28.188] has joined #bitcoin-core-dev 21:17 -!- Guest69 [~Guest69@24.136.28.188] has quit [Client Quit] 21:18 -!- jarthur [~jarthur@2603-8080-1540-002d-b070-785f-6c26-1760.res6.spectrum.com] has joined #bitcoin-core-dev 21:33 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-core-dev 21:36 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 244 seconds] 22:17 -!- earnestly [~earnest@user/earnestly] has joined #bitcoin-core-dev 22:18 -!- Guest29 [~Guest29@69.169.8.135] has joined #bitcoin-core-dev 22:19 < Guest29> balls 22:21 -!- Guest29 [~Guest29@69.169.8.135] has quit [Client Quit] 22:23 -!- roboo [~roboo@217.13.216.18] has joined #bitcoin-core-dev 22:23 < roboo> /ǃ\ TНІS CΗΑΝNEᒪ НАЅ ⅯΟᏙED ᎢO IᏒC.LІBΕᖇА.CHAᎢ #HAϺRAᎠIО /!⧵ 22:23 < roboo> /!\ THE JЕWЅ HAᏙЕ ΤAKEN OⅤER FREᎬΝODE, ϹHATS HAⅤE MOⅤΕᗪ TО ΙRС.LΙⲂᎬRΑ․CዘAT ⧸!﹨ 22:23 -!- roboo [~roboo@217.13.216.18] has quit [K-Lined] 22:52 -!- p3r3grin [~kevin@2601:243:1101:930:6c3c:89cd:591b:49fe] has joined #bitcoin-core-dev 22:56 -!- SenX [~textual@2600:1700:42f0:f60:a9d7:4825:a098:8201] has joined #bitcoin-core-dev 22:58 -!- SenX [~textual@2600:1700:42f0:f60:a9d7:4825:a098:8201] has quit [Client Quit] 23:06 -!- rateliux [ratelius@gateway/vpn/protonvpn/ratelius] has joined #bitcoin-core-dev 23:06 -!- rateliux [ratelius@gateway/vpn/protonvpn/ratelius] has quit [Quit: WeeChat 3.2-dev] 23:06 -!- ratelius [ratelius@gateway/vpn/protonvpn/ratelius] has joined #bitcoin-core-dev 23:21 -!- Guest23 [~Guest23@node-73x.pool-1-10.dynamic.totinternet.net] has joined #bitcoin-core-dev 23:21 -!- Guest23 [~Guest23@node-73x.pool-1-10.dynamic.totinternet.net] has quit [Client Quit] 23:29 -!- p3r3grin [~kevin@2601:243:1101:930:6c3c:89cd:591b:49fe] has quit [Quit: WeeChat 3.1] 23:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/346e52afd6d5...8f5c9a7fd41d 23:39 < bitcoin-git> bitcoin/master ca3a770 Martin Zumsande: test: Fix p2p_leak.py intermittent failure by lowering timeout 23:39 < bitcoin-git> bitcoin/master 8f5c9a7 MarcoFalke: Merge bitcoin/bitcoin#22153: test: Fix p2p_leak.py intermittent failure 23:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:39 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #22153: test: Fix p2p_leak.py intermittent failure (master...202106_fix_p2p_leak) https://github.com/bitcoin/bitcoin/pull/22153 23:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:42 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8f5c9a7fd41d...898dd9e262e4 23:42 < bitcoin-git> bitcoin/master fa2b6c6 MarcoFalke: test: Remove unused node from feature_nulldummy 23:42 < bitcoin-git> bitcoin/master 898dd9e MarcoFalke: Merge bitcoin/bitcoin#22150: test: Remove unused node from feature_nulldum... 23:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 23:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 23:43 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #22150: test: Remove unused node from feature_nulldummy (master...2106-testFaster) https://github.com/bitcoin/bitcoin/pull/22150 23:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] --- Log closed Sat Jun 05 00:00:29 2021