<bitcoin-git>
bitcoin/master 6f8e381 ishaanam: sendall: check if the maxtxfee has been exceeded
<bitcoin-git>
bitcoin/master 718304d MacroFake: Merge bitcoin/bitcoin#26084: sendall: check if the maxtxfee has been excee...
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26084: sendall: check if the maxtxfee has been exceeded (master...sendall_maxtxfee) https://github.com/bitcoin/bitcoin/pull/26084
fjMSX has quit [Read error: Connection reset by peer]
sipsorcery has joined #bitcoin-core-dev
liviudm has quit [Quit: liviudm]
liviudm has joined #bitcoin-core-dev
liviudm has quit [Read error: Connection reset by peer]
liviudm has joined #bitcoin-core-dev
liviudm has quit [Client Quit]
Guyver2 has joined #bitcoin-core-dev
hashfunc has quit [Remote host closed the connection]
<vasild>
sipa: same here (wrt jq), phew! I am not the only one \o/
sipsorcery has quit [Ping timeout: 244 seconds]
<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.
MacroFake_ has joined #bitcoin-core-dev
MacroFake has quit [Ping timeout: 265 seconds]
<vasild>
or if they bombard you with lots of getdata, that would be strange
<glozow>
bip35 mempool should be disabled unless you offer them bip 37 bloom filter services iirc
<vasild>
hmm
bomb-on has joined #bitcoin-core-dev
<vasild>
i briefly checked and got the impression that it is enabled by default...
<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`
<vasild>
right, Implicit is only added from TryParsePermissionFlags()
<vasild>
So, how do spies download the entire pool? Bombard with a lot of getdata messages, but they must already know/guess txids!?
<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.
aleggg has joined #bitcoin-core-dev
jesseposner has quit [Ping timeout: 265 seconds]
<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
<glozow>
yes they must request one by one. to clarify, what do you mean "miss" some?
<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.
aleggg has quit []
<glozow>
oh I see. yes, the spy node only gets what it explicitly requests.
<vasild>
right, and then that must be pretty obvoius because we would get many getdata/tx requests. Would a normal node ever do that?
kexkey has quit [Ping timeout: 265 seconds]
kexkey has joined #bitcoin-core-dev
<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
<glozow>
normal node would not randomly request a bunch of transactions that you didn't announce, no
<glozow>
didn't announce to them*
<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
<vasild>
right, so it must be a spy doing that
<vasild>
glozow: a comment clarification in 26100 ^
aleggg has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 260 seconds]
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 244 seconds]
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 255 seconds]
mikehu44 has joined #bitcoin-core-dev
<hebasto>
linter fails in the master branch with "No parent of HEAD was signed with a trusted key!" message
<fanquake>
probably just gpg failing to retreive keys
chipxxx has joined #bitcoin-core-dev
mikehu44_ has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 250 seconds]
mikehu44_ has quit [Ping timeout: 244 seconds]
mikehu44 has joined #bitcoin-core-dev
mikehu44_ has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 260 seconds]
jesseposner has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
jesseposner has quit [Ping timeout: 244 seconds]
jesseposner has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
mikehu44_ has quit [Ping timeout: 260 seconds]
mikehu44 has quit [Quit: No Ping reply in 180 seconds.]
mikehu44 has joined #bitcoin-core-dev
ziggie has joined #bitcoin-core-dev
dermoth has joined #bitcoin-core-dev
<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
<vasild>
could be
<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
<vasild>
it seems that it would be useful to have global detailed traffic stats, like the ones we have per connected peer, but global.
<sipa>
agree
<sipa>
or broken down by peer type
<vasild>
you mean inbound vs outbound?
<sipa>
yeah, and block-relay-only / full-outbound / addrfetch / ...
<vasild>
that too... some jq mastery would be required to aggregate it, but I think it would be ok
jesseposner has quit [Ping timeout: 244 seconds]
jesseposner has joined #bitcoin-core-dev
jesseposner has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
<_aj_>
sipa: make `bitcoin-cli getnetworkinfo | jq .bytessent.full-outbound.inv` report cumulative stats (so you still have info after a peer disconnects)?
<fanquake>
hopefully created that wiki page correctly
<fanquake>
have also just gone through the "Needs release note" label and removed basically everything, as it was pretty much leftovers from previous releases
<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
<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
vasild has quit [Ping timeout: 258 seconds]
vasild has joined #bitcoin-core-dev
<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
kexkey has quit [Ping timeout: 265 seconds]
kexkey has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
<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
<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
baldur has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
baldur has joined #bitcoin-core-dev
szkl has quit [Quit: Connection closed for inactivity]
<laanwj>
i noticed those a few days ago then forgot to comment
<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.
<laanwj>
MacroFake: right, backports makes sense for things that come as a surprise, not what has been open already for a while
<MacroFake>
Maybe #26005 can be merged an someone picks up the feedback in a follow-up?
<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
<laanwj>
ok, so i think the answer is no, no branch-off today, there are still some things that need to go in
<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)
<MacroFake>
lightlike: Did you try to force the failed commit, or just run the unit test as is?
<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.
<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
<MacroFake>
ok, I might take another look tomorrow, but otherwise it shouldn't block rc1 for now
<MacroFake>
#25985 is just a performance thing, and not even a regression, so shouldn't block rc1 either
<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
sipsorcery has quit [Ping timeout: 268 seconds]
<fanquake>
Although this is also easy to backport, so doesn't matter too much
<achow101>
It also doesn't have any effect on our release binaries
<laanwj>
doesn't seem too risky to merge an OSX specific build system revert?
sipsorcery has joined #bitcoin-core-dev
<fanquake>
Yea, any risk is limited to compiling on macOS, which is why it's mostly devs posting issues
<laanwj>
#topic important changes in 24.0 to cover in the new RC Testing Guide (kouloumos)
<core-meetingbot>
topic: important changes in 24.0 to cover in the new RC Testing Guide (kouloumos)
<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.
<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.
<kouloumos>
The changes I've included are:
<kouloumos>
1) Using the GUI to restore a wallet from a backup file (#471)
<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.
<lightlike>
yes, the test guide should recommend to use an empty datadir for that.
<kouloumos>
Yes, that's already suggested on every test.
<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
<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!
<kouloumos>
Note: I'll also need write access to bitcoindev-wiki to add the guide.
<sipa>
Feel free to ping me here if you have questions.
<kouloumos>
I'll do! thanks
<laanwj>
ok let's give you write access to the wiki
<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
<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
<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
sipsorcery has quit [Read error: Connection reset by peer]
brunoerg has quit []
sipsorcery has joined #bitcoin-core-dev
halosghost has quit [Quit: WeeChat 3.6]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
sipsorcery has quit [Ping timeout: 264 seconds]
kouloumos has quit [Quit: Connection closed for inactivity]
F1nny has joined #bitcoin-core-dev
<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
<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?
<robertspigler>
I have ~40 connections, mostly IPv4 and a handful Onion, each both way