--- Log opened Thu Sep 15 00:00:19 2022
00:02 -!- fjMSX [~hypni2p@128-68-144-58.broadband.corbina.ru] has quit [Read error: Connection reset by peer]
00:02 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev
00:10 -!- liviudm [~textual@112.206.107.43] has quit [Quit: liviudm]
00:12 -!- liviudm [~liviudm@112.206.107.43] has joined #bitcoin-core-dev
00:15 -!- liviudm [~liviudm@112.206.107.43] has quit [Read error: Connection reset by peer]
00:16 -!- liviudm [~liviudm@112.206.107.43] has joined #bitcoin-core-dev
00:17 -!- liviudm [~liviudm@112.206.107.43] has quit [Client Quit]
00:18 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:01 -!- hashfunc [~user@2601:5c0:c280:7090:83:ebf7:f91d:450a] has quit [Remote host closed the connection]
01:10 < vasild> sipa: same here (wrt jq), phew! I am not the only one \o/
01:12 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 244 seconds]
01:24 < vasild> "my guess is these numbers are very skewed by spy nodes that download all transactions" -- I guess it is possible to cross-check if this is the case by looking at how many MEMPOOL messages you received, assuming spies send MEMPOOL.
01:25 -!- MacroFake_ [~none@72.5.34.65] has joined #bitcoin-core-dev
01:25 -!- MacroFake [~none@72.5.34.65] has quit [Ping timeout: 265 seconds]
01:26 < vasild> or if they bombard you with lots of getdata, that would be strange
01:26 < glozow> bip35 mempool should be disabled unless you offer them bip 37 bloom filter services iirc
01:26 < vasild> hmm
01:27 -!- bomb-on [~bomb-on@user/bomb-on] has joined #bitcoin-core-dev
01:27 < vasild> i briefly checked and got the impression that it is enabled by default...
01:29 < vasild> glozow: here: https://github.com/bitcoin/bitcoin/blob/a8f69541ad53a76d5f69044ba829069d225a4af1/src/net.cpp#L946
01:29 < glozow> see https://github.com/bitcoin/bitcoin/blob/718304d222671f98d2335cd9b90a3022f62d7b21/src/net_processing.cpp#L4487-L4513
01:30 < glozow> I'm not 100% correct, either we offer bloom services or they have mempool permissions. but neither are on by default
01:31 -!- MacroFake_ [~none@72.5.34.65] has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
01:32 -!- MacroFake [~none@72.5.34.65] has joined #bitcoin-core-dev
01:32 < vasild> it looks to me mempool permission is on by default
01:33 -!- aleggg [~aleggg@186.213.136.32] has quit []
01:33 < glozow> that is gated under `if (NetPermissions::HasFlag(permissionFlags, NetPermissionFlags::Implicit)) {`
01:34 < glozow> I may be wrong, but I don't think that is the default?
01:35 < vasild> this comment: https://github.com/bitcoin/bitcoin/blob/a8f69541ad53a76d5f69044ba829069d225a4af1/src/net_permissions.h#L38
01:37 -!- fjMSX [~hypni2p@128-68-144-58.broadband.corbina.ru] has joined #bitcoin-core-dev
01:38 < glozow> I think you are misinterpreting the comment. It's "user not set fine-grained permissions," as in they set `-whitelist=address` and did not specify something like `-whitelist=noban@address`
01:39 < vasild> right, Implicit is only added from TryParsePermissionFlags()
01:40 < vasild> So, how do spies download the entire pool? Bombard with a lot of getdata messages, but they must already know/guess txids!?
01:45 < glozow> Sorry I don't have a lot of context on the original conversation, just popped in because you said "mempool" haha. They can query you for transactions they know about (but we try not to just serve everything we have immediately, see `FindTxForGetData`), or keep logs of what you announce.
01:46 -!- aleggg [~aleggg@186.213.136.32] has joined #bitcoin-core-dev
01:47 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 265 seconds]
01:49 < vasild> yeah, that means they already know the txid and only check if you have it, but then to download the entire pool one needs to request individual transactions one by one and then this method is not exhaustive - it could miss some txs
01:50 < glozow> yes they must request one by one. to clarify, what do you mean "miss" some?
01:52 < vasild> that some transactions could be missed from this download procedure, e.g. if you have tx1, tx2 and tx3 and they request tx1 and tx2, but they do not know and thus do not request tx3, then tx3 will not be downloaded. So it is not like downloading the _entire_ pool.
01:52 -!- aleggg [~aleggg@186.213.136.32] has quit []
01:55 < glozow> oh I see. yes, the spy node only gets what it explicitly requests.
02:02 < vasild> right, and then that must be pretty obvoius because we would get many getdata/tx requests. Would a normal node ever do that?
02:04 -!- kexkey [~kexkey@178.249.214.10] has quit [Ping timeout: 265 seconds]
02:05 -!- kexkey [~kexkey@static-198-54-132-86.cust.tzulo.com] has joined #bitcoin-core-dev
02:13 < bitcoin-git> [bitcoin] fanquake opened pull request #26099: build: remove duplicate / unneeded libs from bench_bitcoin (master...bench_duplicate_linking) https://github.com/bitcoin/bitcoin/pull/26099
02:13 < glozow> normal node would not randomly request a bunch of transactions that you didn't announce, no
02:14 < glozow> didn't announce to them*
02:22 < bitcoin-git> [bitcoin] vasild opened pull request #26100: doc: clarify that NetPermissionFlags::Implicit is only about whitelists (master...netperm_implicit_comment) https://github.com/bitcoin/bitcoin/pull/26100
02:23 < vasild> right, so it must be a spy doing that
02:23 < vasild> glozow: a comment clarification in 26100 ^
02:39 -!- aleggg [~aleggg@186.213.136.32] has joined #bitcoin-core-dev
02:58 -!- mikehu44 [~quassel@159.65.11.175] has quit [Ping timeout: 260 seconds]
03:00 -!- mikehu44 [~quassel@gateway/vpn/pia/mikehu44-jc] has joined #bitcoin-core-dev
03:06 -!- mikehu44 [~quassel@gateway/vpn/pia/mikehu44-jc] has quit [Ping timeout: 244 seconds]
03:13 -!- mikehu44 [~quassel@gateway/vpn/pia/mikehu44-jc] has joined #bitcoin-core-dev
03:18 -!- mikehu44 [~quassel@gateway/vpn/pia/mikehu44-jc] has quit [Ping timeout: 255 seconds]
03:18 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev
03:24 < hebasto> linter fails in the master branch with "No parent of HEAD was signed with a trusted key!" message
03:30 < fanquake> probably just gpg failing to retreive keys
03:41 -!- chipxxx [~chip@pop.92-184-107-20.mobile.abo.orange.fr] has joined #bitcoin-core-dev
03:51 -!- mikehu44_ [~quassel@159.65.11.175] has joined #bitcoin-core-dev
03:52 -!- mikehu44 [~quassel@159.65.11.175] has quit [Ping timeout: 250 seconds]
04:03 -!- mikehu44_ [~quassel@159.65.11.175] has quit [Ping timeout: 244 seconds]
04:05 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev
04:20 -!- mikehu44_ [~quassel@159.65.11.175] has joined #bitcoin-core-dev
04:21 -!- mikehu44 [~quassel@159.65.11.175] has quit [Ping timeout: 260 seconds]
04:25 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-dev
04:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:35 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 244 seconds]
04:38 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-dev
04:40 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev
04:42 -!- mikehu44_ [~quassel@159.65.11.175] has quit [Ping timeout: 260 seconds]
04:47 -!- mikehu44 [~quassel@159.65.11.175] has quit [Quit: No Ping reply in 180 seconds.]
04:48 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev
04:58 -!- ziggie [uid521459@user/ziggie] has joined #bitcoin-core-dev
05:03 -!- dermoth [~dermoth@user/dermoth] has joined #bitcoin-core-dev
05:37 < sipa> @vasild I haven't investigated what these spies are doing (or if that's what's happening at all), but one theory is that they aggressively ask for all transactions we announce, including ones they have already received from other nodes
05:38 < vasild> could be
05:39 < sipa> unfortunately, if a significant portion of our bandwidth is being consumed by just such nodes behaving undesirably, then erlay will not actually impact total tx bandwidth much, even when increasing peers... at least not without other measures
05:39 < vasild> it seems that it would be useful to have global detailed traffic stats, like the ones we have per connected peer, but global.
05:39 < sipa> agree
05:39 < sipa> or broken down by peer type
05:39 < vasild> you mean inbound vs outbound?
05:40 < sipa> yeah, and block-relay-only / full-outbound / addrfetch / ...
05:41 < vasild> that too... some jq mastery would be required to aggregate it, but I think it would be ok
05:43 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 244 seconds]
05:45 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-dev
05:54 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 265 seconds]
06:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:38cb:b7c9:7f5b:7bc9] has joined #bitcoin-core-dev
06:15 < _aj_> sipa: make `bitcoin-cli getnetworkinfo | jq .bytessent.full-outbound.inv` report cumulative stats (so you still have info after a peer disconnects)?
06:16 < sipa> _aj_: That'd be useful, I think.
06:23 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has joined #bitcoin-core-dev
06:28 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-dev
06:41 -!- mikehu44 [~quassel@159.65.11.175] has quit [Ping timeout: 268 seconds]
06:47 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 268 seconds]
06:47 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev
06:49 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-dev
07:21 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/718304d22267...20f03a5aedc2
07:22 < bitcoin-git> bitcoin/master afce044 fanquake: build: remove unused natpmp / upnp cppflags
07:22 < bitcoin-git> bitcoin/master 4b656b9 fanquake: build: remove unused libevent cppflags
07:22 < bitcoin-git> bitcoin/master 20f03a5 fanquake: Merge bitcoin/bitcoin#26089: build: remove unused cppflags
07:22 < bitcoin-git> [bitcoin] fanquake merged pull request #26089: build: remove unused cppflags (master...prune_unneeded_upnp_natpmp) https://github.com/bitcoin/bitcoin/pull/26089
07:26 -!- halosghost [~halosghos@user/halosghost] has joined #bitcoin-core-dev
07:32 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/20f03a5aedc2...f332c4f64d52
07:32 < bitcoin-git> bitcoin/master 02c9e56 Cory Fields: fs: fully initialize _OVERLAPPED for win32
07:32 < bitcoin-git> bitcoin/master f332c4f fanquake: Merge bitcoin/bitcoin#26090: fs: fully initialize `_OVERLAPPED` for win32
07:32 < bitcoin-git> [bitcoin] fanquake merged pull request #26090: fs: fully initialize `_OVERLAPPED` for win32 (master...fixup_overlapped_init_win32) https://github.com/bitcoin/bitcoin/pull/26090
07:47 -!- mikehu44 [~quassel@159.65.11.175] has quit [Ping timeout: 264 seconds]
07:49 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev
07:59 -!- chipxxx [~chip@pop.92-184-107-20.mobile.abo.orange.fr] has quit [Read error: Connection reset by peer]
08:04 -!- mikehu44 [~quassel@159.65.11.175] has quit [Ping timeout: 252 seconds]
08:26 < fanquake> I've moved the consolidated release note snippets from #26093 over into https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft
08:26 <@gribble> https://github.com/bitcoin/bitcoin/issues/26093 | doc: consolidate release-note fragments pre-wiki by fanquake · Pull Request #26093 · bitcoin/bitcoin · GitHub
08:26 < fanquake> hopefully created that wiki page correctly
08:26 < fanquake> have also just gone through the "Needs release note" label and removed basically everything, as it was pretty much leftovers from previous releases
08:27 < fanquake> if there is anything on https://github.com/bitcoin/bitcoin/milestone/54 that needs notes, or something that will be in 24.x that is missing from the milestone and needs notes, please point it out / add to the wiki etc
08:28 < bitcoin-git> [bitcoin] theuni opened pull request #26101: script: create V1SigVersion for functions which should only accept taproot/tapscript (master...explicit-v1-scriptver) https://github.com/bitcoin/bitcoin/pull/26101
09:02 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 258 seconds]
09:03 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
09:26 < bitcoin-git> [bitcoin] aureleoules opened pull request #26102: test: test_runner option to run tests in priority (master...2022-09-test-runner-priority) https://github.com/bitcoin/bitcoin/pull/26102
09:34 -!- kexkey [~kexkey@static-198-54-132-86.cust.tzulo.com] has quit [Ping timeout: 265 seconds]
09:35 -!- kexkey [~kexkey@178.249.214.10] has joined #bitcoin-core-dev
09:37 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
09:56 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
10:18 < bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/f332c4f64d52...96f1b2d34fd5
10:18 < bitcoin-git> bitcoin/master faa4916 MacroFake: test/doc: Remove unused syncwithvalidationinterfacequeue
10:18 < bitcoin-git> bitcoin/master fa1ce96 MacroFake: test: Add missing syncwithvalidationinterfacequeue
10:18 < bitcoin-git> bitcoin/master 96f1b2d Andrew Chow: Merge bitcoin/bitcoin#26091: test: Fix syncwithvalidationinterfacequeue ca...
10:18 < bitcoin-git> [bitcoin] achow101 merged pull request #26091: test: Fix syncwithvalidationinterfacequeue calls (master...2209-test-fix-🔻) https://github.com/bitcoin/bitcoin/pull/26091
10:27 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/96f1b2d34fd5...a56876e6b9da
10:27 < bitcoin-git> bitcoin/master cc434cb kouloumos: wallet: fix sendall creates tx that fails tx-size check
10:27 < bitcoin-git> bitcoin/master a56876e Andrew Chow: Merge bitcoin/bitcoin#26024: wallet: fix sendall creates tx that fails tx-...
10:27 < bitcoin-git> [bitcoin] achow101 merged pull request #26024: wallet: fix sendall creates tx that fails tx-size check (master...wallet-fix-sendall-tx-size) https://github.com/bitcoin/bitcoin/pull/26024
10:54 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has joined #bitcoin-core-dev
10:59 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 258 seconds]
11:04 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
11:19 < bitcoin-git> [bitcoin] sipa closed pull request #26065: i2p: use the same destination type for transient and persistent addresses (master...i2p_transient_addr_type) https://github.com/bitcoin/bitcoin/pull/26065
11:19 < bitcoin-git> [bitcoin] sipa reopened pull request #26065: i2p: use the same destination type for transient and persistent addresses (master...i2p_transient_addr_type) https://github.com/bitcoin/bitcoin/pull/26065
11:21 -!- baldur [~baldur@pool-74-108-229-157.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
11:28 -!- sipsorcery [~sipsorcer@37.228.225.67] has joined #bitcoin-core-dev
11:30 -!- baldur [~baldur@pool-74-108-229-157.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
11:37 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
11:58 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
12:01 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
12:03 < achow101> meeting?
12:04 < laanwj> #startmeeting
12:04 <@core-meetingbot> Meeting started Thu Sep 15 19:04:04 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
12:04 <@core-meetingbot> Available commands: action commands idea info link nick
12:04 < achow101> hi
12:04 < fanquake> hi
12:04 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 244 seconds]
12:04 < laanwj> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard b10c 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 larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo
12:04 < laanwj> moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
12:04 < laanwj> welcome to the weekly bitcoin-core-dev meeting
12:04 < jarolrod> hi
12:04 < kouloumos> hi
12:04 < laanwj> one proposed meeting topic this week: important changes in 24.0 to cover in the new RC Testing Guide (kouloumos)
12:05 < ajonas> hi
12:05 < lightlike> hi
12:05 < kanzure> hi
12:05 < achow101> will we be branching today too?
12:05 < furszy> hi
12:05 < cfields> hi
12:06 < sipa> hi
12:06 < laanwj> achow101: that's another topic to discuss
12:06 < kouloumos> should I go first or we are discussing high-priority first?
12:07 < hebasto> hi
12:07 < laanwj> we don't do high priority at the moment, though we could go over the milesteone
12:08 < fanquake> https://github.com/bitcoin/bitcoin/milestone/54
12:08 < laanwj> it seems that there's still some PRs open that need to go in before the split-off- anyhow
12:08 < MacroFake> Yeah, backporting one or two things is fine, but 5 seems too much
12:08 < laanwj> fanquake: ah im glad you noticed the release fragments in doc/release-notes, in #26093
12:08 <@gribble> https://github.com/bitcoin/bitcoin/issues/26093 | doc: consolidate release-note fragments pre-wiki by fanquake · Pull Request #26093 · bitcoin/bitcoin · GitHub
12:09 < laanwj> i noticed those a few days ago then forgot to comment
12:09 < fanquake> A couple PRs on the milestone almost ready for merge. The few others likely be resolved / mergable in the next day or so I think.
12:10 < laanwj> MacroFake: right, backports makes sense for things that come as a surprise, not what has been open already for a while
12:11 < MacroFake> Maybe #26005 can be merged an someone picks up the feedback in a follow-up?
12:11 <@gribble> https://github.com/bitcoin/bitcoin/issues/26005 | Wallet: Fix error handling (copy_file failure in RestoreWallet, and in general via interfaces) by luke-jr · Pull Request #26005 · bitcoin/bitcoin · GitHub
12:11 < laanwj> ok, so i think the answer is no, no branch-off today, there are still some things that need to go in
12:12 < lightlike> #26068 doesn't look likely to be resolved in the near future (at least I don't know why it happens / couldn't reproduce)
12:12 <@gribble> https://github.com/bitcoin/bitcoin/issues/26068 | Segmentation fault in the scheduler thread when an index fails to commit to the db · Issue #26068 · bitcoin/bitcoin · GitHub
12:12 < achow101> MacroFake: I think that's reasonable
12:13 < MacroFake> lightlike: Did you try to force the failed commit, or just run the unit test as is?
12:14 < MacroFake> Locally I can't reproduce almost no issue seen in the CI and usually I have to modify the source code to force a sleep in the right place or so.
12:15 < lightlike> MacroFake: ran the test as it, and tried to change order of subtests in the src file to see if that could have been the reason, because in the failed CI runs the second subtest was run before the first one
12:16 < MacroFake> ok, I might take another look tomorrow, but otherwise it shouldn't block rc1 for now
12:17 < MacroFake> #25985 is just a performance thing, and not even a regression, so shouldn't block rc1 either
12:17 <@gribble> https://github.com/bitcoin/bitcoin/issues/25985 | Revert "build: Use Homebrews sqlite package if it is available" by fanquake · Pull Request #25985 · bitcoin/bitcoin · GitHub
12:17 < fanquake> I somewhat disagree
12:18 < fanquake> It's causing continual confusion downstream, a new report overnight of devs becoming confused over terrible performance, this time in BDK: https://github.com/bitcoindevkit/bdk/issues/749
12:18 -!- sipsorcery [~sipsorcer@37.228.225.67] has quit [Ping timeout: 268 seconds]
12:19 < fanquake> Although this is also easy to backport, so doesn't matter too much
12:20 < achow101> It also doesn't have any effect on our release binaries
12:20 < laanwj> doesn't seem too risky to merge an OSX specific build system revert?
12:20 -!- sipsorcery [~sipsorcer@37.228.225.67] has joined #bitcoin-core-dev
12:21 < fanquake> Yea, any risk is limited to compiling on macOS, which is why it's mostly devs posting issues
12:23 < laanwj> #topic important changes in 24.0 to cover in the new RC Testing Guide (kouloumos)
12:23 <@core-meetingbot> topic: important changes in 24.0 to cover in the new RC Testing Guide (kouloumos)
12:23 < kouloumos> I'm working on the 24.0 RC Testing Guide and I'd like to get some feedback on which changes are considered important and useful to test. 
12:23 < kouloumos> The current version is available here: https://gist.github.com/kouloumos/fc112640a533e522d435c0995dcaaaf4  
12:23 < kouloumos> From the release notes ( https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft ), I've already included testing guidance for 4 changes that I think most worthwhile to test and I have 1 pending. I'd appreciate feedback on if you think anything else should be included, and if maybe something can be omitted.
12:24 < kouloumos> The changes I've included are:
12:24 < kouloumos> 1)  Using the GUI to restore a wallet from a backup file (#471)
12:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/471 | DbException after Ctrl+C on bitcoind.exe (Windows) · Issue #471 · bitcoin/bitcoin · GitHub
12:24 < kouloumos> 2) Peristent settings are now unified between bitcoind and the GUI. (#15936,#602)
12:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/15936 | interfaces: Expose settings.json methods to GUI by ryanofsky · Pull Request #15936 · bitcoin/bitcoin · GitHub
12:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/602 | Cleaned up critical section code. by cgaebel · Pull Request #602 · bitcoin/bitcoin · GitHub
12:24 < kouloumos> 3) Using the new migratewallet RPC to migrate legacy wallets to descriptor wallets. (#19602)
12:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/19602 | wallet: Migrate legacy wallets to descriptor wallets by achow101 · Pull Request #19602 · bitcoin/bitcoin · GitHub
12:24 < kouloumos> 4) Wallet support for watchonly Miniscript descriptors. (#24148)
12:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/24148 | Miniscript support in Output Descriptors by darosior · Pull Request #24148 · bitcoin/bitcoin · GitHub
12:24 < kouloumos> The additional change that I am planning to add is:
12:24 < kouloumos> 5) The new `sendall` RPC, useful to empty wallets or to create a changeless payment from select UTXOs. (#24118)
12:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/24118 | Add sendall RPC née sweep by Xekyo · Pull Request #24118 · bitcoin/bitcoin · GitHub
12:24 < kouloumos> Also, glozow suggested, and I am currently looking at:
12:24 < kouloumos> 6) Observe pre-syncing step during IBD (#25717)
12:25 <@gribble> https://github.com/bitcoin/bitcoin/issues/25717 | p2p: Implement anti-DoS headers sync by sdaftuar · Pull Request #25717 · bitcoin/bitcoin · GitHub
12:25 < kouloumos> 7) Try new RPC gettxspendingprevout (#25874)  8) Try -mempoolfullrbf option (#25353)
12:25 <@gribble> https://github.com/bitcoin/bitcoin/issues/25874 | BIP155 CJDNS address with length 187 (should be 16) · Issue #25874 · bitcoin/bitcoin · GitHub
12:25 <@gribble> https://github.com/bitcoin/bitcoin/issues/25353 | Add a `-mempoolfullrbf` node setting by ariard · Pull Request #25353 · bitcoin/bitcoin · GitHub
12:25 < sipa> Cool
12:25 < lightlike> +1 for #25717 - can be tested by syncing headers on mainnet, testnet etc. with -stopatheight=1000 or so, with or without gui
12:25 <@gribble> https://github.com/bitcoin/bitcoin/issues/25717 | p2p: Implement anti-DoS headers sync by sdaftuar · Pull Request #25717 · bitcoin/bitcoin · GitHub
12:26 < kouloumos> lightlike: appreciate the suggestion! 
12:28 < sipa> For 25717 observing the pre-syncing phase is one thing (it should be there), but arguably the more interesting property is that syncing still works at all. It's only triggered when syncing a new node from scratch, or one that is ~months or more behind.
12:29 < lightlike> yes, the test guide should recommend to use an empty datadir for that.
12:30 < kouloumos> Yes, that's already suggested on every test.
12:32 < bitcoin-git> [bitcoin] stickies-v opened pull request #26103: refactor: mempool: use CTxMemPool::Limits (master...mempool-simplify-fn-signatures) https://github.com/bitcoin/bitcoin/pull/26103
12:32 < kouloumos> Great! thank you everyone, I'll look into including 25717 and give progress updates in https://github.com/bitcoin/bitcoin/issues/26092 . Please reach out with ideas and feedback. Thanks!
12:32 < kouloumos> Note: I'll also need write access to bitcoindev-wiki to add the guide.
12:32 < sipa> Feel free to ping me here if you have questions.
12:34 < kouloumos> I'll do! thanks
12:36 < laanwj> ok let's give you write access to the wiki
12:37 < laanwj> any other topics?
12:38 < laanwj> appparently not, let's close the meeting
12:38 < laanwj> #endmeeting
12:38 <@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:38 <@core-meetingbot> Meeting ended Thu Sep 15 19:38:56 2022 UTC.  
12:38 <@core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2022/bitcoin-core-dev.2022-09-15-19.04.moin.txt
12:43 < bitcoin-git> [bitcoin] Xekyo opened pull request #26104: Check whether feerate is higher than long_term_feerate only once (master...2022-09-high-feerate-optimization) https://github.com/bitcoin/bitcoin/pull/26104
13:02 < bitcoin-git> [bitcoin] Xekyo closed pull request #26104: coin selection: Check whether feerate is higher than long_term_feerate only once (master...2022-09-high-feerate-optimization) https://github.com/bitcoin/bitcoin/pull/26104
13:50 < bitcoin-git> [bitcoin] sipa opened pull request #26105: Use ReadLE64 in uint256::GetUint64 instead of duplicating logic (master...202209_uint256_readle64) https://github.com/bitcoin/bitcoin/pull/26105
13:52 -!- sipsorcery [~sipsorcer@37.228.225.67] has quit [Read error: Connection reset by peer]
13:56 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:38cb:b7c9:7f5b:7bc9] has quit []
13:58 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev
14:27 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.6]
14:27 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:57 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 264 seconds]
15:14 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:21 -!- F1nny [~f1nny@user/f1nny] has joined #bitcoin-core-dev
15:23 < robertspigler> Not 24.0 testing related, but I have been running 23.0 with i2prouter with `i2psam=127.0.0.1:7656` and `i2pacceptincoming=1` with my port forwarded.  I know I am well connected because the console shows that I have used over 30GB bandwidth both in and out in ~5 days, have over 4,000 peers and over 10 tunnels. However, I had no automatically connected I2P peers, and after connecting to a few manual outbound I2P peers from
15:23 < robertspigler> bitcoin/contrib/seeds/nodes_main.txt, I still don't have any automatic outbound or inbound I2P peers. Is this an issue with preferential peering?
15:24 < robertspigler> I have ~40 connections, mostly IPv4 and a handful Onion, each both way
15:29 -!- bomb-on [~bomb-on@user/bomb-on] has quit [Quit: aллилѹіа!]
15:38 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-dev
16:14 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 268 seconds]
16:33 -!- Evel-Knievel [~Evel-Knie@user/evel-knievel] has quit [Ping timeout: 252 seconds]
16:34 -!- Evel-Knievel [~Evel-Knie@user/evel-knievel] has joined #bitcoin-core-dev
17:05 < _aj_> robertspigler: maybe just means most i2p nodes aren't i2p-only (and thus make most of their outbound connections on ipv4/ipv6/onion)?
17:24 -!- _apex_ [~apex@dynamic-acs-24-144-190-15.zoominternet.net] has joined #bitcoin-core-dev
17:28 -!- _apex2_ [~apex@dynamic-acs-24-144-190-15.zoominternet.net] has joined #bitcoin-core-dev
17:31 -!- _apex_ [~apex@dynamic-acs-24-144-190-15.zoominternet.net] has quit [Ping timeout: 252 seconds]
17:33 -!- gleb1068924 [~gleb@178.150.137.228] has quit [Quit: Ping timeout (120 seconds)]
17:34 -!- gleb1068924 [~gleb@178.150.137.228] has joined #bitcoin-core-dev
17:42 -!- dougefish_ [~dougefish@77.137.68.0] has quit [Ping timeout: 244 seconds]
18:21 -!- gleb10689249 [~gleb@178.150.137.228] has joined #bitcoin-core-dev
18:22 -!- gleb1068924 [~gleb@178.150.137.228] has quit [Ping timeout: 252 seconds]
19:02 -!- _apex2_ [~apex@dynamic-acs-24-144-190-15.zoominternet.net] has quit [Ping timeout: 268 seconds]
19:09 < lightlike> also, it could be a bit of a chicken-and-egg problem: If you start out with an addrman that has predominantly clearnet peers, your chance to pick an i2p peer for an outgoing connection is small. But if you don't make outgoing connections to i2p peers, you probably won't advertise your i2p address  but your clearnet address, so that your i2p address won't  propagate to other i2p peers. As a result you also won't get incoming i2p peers 
19:09 < lightlike> because others don't know you exist.
19:12 < robertspigler> Makes sense
19:13 < robertspigler> _aj_: Should there not be a preference to make atleast 1 i2p connection for network diversity sake
19:13 -!- _apex2_ [~apex@dynamic-acs-24-144-190-15.zoominternet.net] has joined #bitcoin-core-dev
19:23 < _aj_> lightlike: that sounds suboptimal?
19:26 < _aj_> robertspigler: i could see biasing addrfetch and the temporary block-relay-only connections to ensure connections are regularly made to each reachable net, to help maintain connectivity; but biasing a permanent connection might be risky?
19:27 -!- dougefish [~dougefish@5.29.13.210] has joined #bitcoin-core-dev
19:30 -!- dougefish [~dougefish@5.29.13.210] has quit [Remote host closed the connection]
19:32 -!- _apex2_ [~apex@dynamic-acs-24-144-190-15.zoominternet.net] has quit [Ping timeout: 252 seconds]
19:51 -!- mikehu44 [~quassel@159.65.11.175] has joined #bitcoin-core-dev
20:16 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
20:17 -!- mikehu44 [~quassel@159.65.11.175] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
20:29 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
20:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:03 -!- af_mencken [~afmencken@69.4.234.55] has joined #bitcoin-core-dev
21:06 -!- afmencken [~afmencken@69.4.234.100] has quit [Ping timeout: 244 seconds]
22:10 < bitcoin-git> [bitcoin] hobhsy opened pull request #26106: [![C/C++ CI](https://github.com/hobhsy/haha/actions/workflows/c-cpp.yml/badge.svg?branch=master&event=pull_request_review_comment)](https://github.com/hobhsy/haha/actions/workflows/c-cpp.yml) (master...master) https://github.com/bitcoin/bitcoin/pull/26106
22:23 -!- realies [~realies@user/realies] has quit [Quit: Ping timeout (120 seconds)]
22:23 -!- realies [~realies@user/realies] has joined #bitcoin-core-dev
22:42 -!- dougefish [~dougefish@2a00:a040:199:52c1:1ac0:4dff:fe34:3985] has joined #bitcoin-core-dev
22:57 < bitcoin-git> [bitcoin] fanquake closed pull request #26106: [![C/C++ CI](https://github.com/hobhsy/haha/actions/workflows/c-cpp.yml/badge.svg?branch=master&event=pull_request_review_comment)](https://github.com/hobhsy/haha/actions/workflows/c-cpp.yml) (master...master) https://github.com/bitcoin/bitcoin/pull/26106
23:32 < vasild> robertspigler: lightlike: _aj_: indeed if addrman has just e.g. 5% i2p peers, then the chance of randomly selecting one is... well... 5%
23:33 < vasild> for outbound 10 connections that means 0 i2p peers
23:34 < _aj_> 40% chance of at least 1 peer at 5% each
23:34 < vasild> I have been thinking before to change the logic of "randomly" selecting outbound peers. This is very much related to #26035
23:34 <@gribble> https://github.com/bitcoin/bitcoin/issues/26035 | Finding peers to connect to after -onlynet changes may be problematic · Issue #26035 · bitcoin/bitcoin · GitHub
23:36 < vasild> what about this: try to maintain at least 1 outbound to each reachable network? so when choosing a peer to connect to, ask addrman to give us a random i2p peer if we dont have i2p out connections and i2p is reachable
23:37 < vasild> s/i2p/any reachable network/
23:39 < vasild> _aj_: how did you derive that 40%?
23:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a56876e6b9da...27351fb9159e
23:39 < bitcoin-git> bitcoin/master b0349a7 fanquake: doc: consolidate & remove release-note fragments
23:39 < bitcoin-git> bitcoin/master 27351fb MacroFake: Merge bitcoin/bitcoin#26093: doc: consolidate release-note fragments pre-w...
23:39 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #26093: doc: consolidate release-note fragments pre-wiki (master...consolidate_release_notes) https://github.com/bitcoin/bitcoin/pull/26093
23:39 < _aj_> 1-((1-0.05)**10)
23:41 < vasild> +1
23:46 < vasild> in my addrman: total: 68234, ipv4: 46391, onion: 11491, ipv6: 10237, i2p: 111, cjdns: 4
23:50 < vasild> _aj_: so, at least for my addrman, that is 1.6% instead of 40% :/
23:51 -!- baldur [~baldur@pool-74-108-229-157.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
23:53 < vasild> that node has 12 inbound and 0 outbound i2p connections
23:54 < _aj_> vasild: yeah, that sounds more plausible
23:54 -!- baldur [~baldur@pool-74-108-229-157.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
23:55 < _aj_> vasild: lot of inbounds, but i guess your node was early or is a seed node?
23:55 < vasild> was early for sure, maybe also is a seed one
23:56 < _aj_> i think early would help if it's selected as a block-relay-only node by i2p-only peers
--- Log closed Fri Sep 16 00:00:06 2022