<bitcoin-git>
[bitcoin] fanquake merged pull request #25838: build, qt: Use `mkspecs/bitcoin-linux-g++` for all Linux hosts (master...220813-mkspec) https://github.com/bitcoin/bitcoin/pull/25838
justache has quit [Remote host closed the connection]
justache has joined #bitcoin-core-dev
justache has quit [Remote host closed the connection]
justache has joined #bitcoin-core-dev
justache has quit [Remote host closed the connection]
MacroFake has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
MacroFake has joined #bitcoin-core-dev
Guyver2_ has joined #bitcoin-core-dev
Guyver2 has quit [Ping timeout: 256 seconds]
sudoforge has joined #bitcoin-core-dev
MacroFake has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
MacroFake has joined #bitcoin-core-dev
Guest7 has joined #bitcoin-core-dev
Guest7 has quit [Client Quit]
Guest7 has joined #bitcoin-core-dev
Guest7 has quit [Client Quit]
jonatack has quit [Ping timeout: 248 seconds]
justache has quit [Remote host closed the connection]
justache has joined #bitcoin-core-dev
mimmy has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
pablomartin has joined #bitcoin-core-dev
mimmy has quit [Ping timeout: 256 seconds]
mimmy has joined #bitcoin-core-dev
mimmy has quit [Client Quit]
Guest42 has joined #bitcoin-core-dev
Guest42 has quit [Client Quit]
bitdex has quit [Ping timeout: 268 seconds]
jarthur has joined #bitcoin-core-dev
<laanwj>
MacroFake: agree, may want to make a 0.18-final tag first if there's commits on that branch that haven't made it into a release, if not it can just be removed
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
pablomartin has quit [Quit: Leaving]
SpellChecker has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
SpellChecker has joined #bitcoin-core-dev
Guyver2_ has left #bitcoin-core-dev [#bitcoin-core-dev]
andrewtoth_ has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 248 seconds]
<S3RK>
I don't see CI running for the latest push in #25647 ? How can I kick it?
<bitcoin-git>
bitcoin/master 05f7f31 Suhas Daftuar: Reduce bandwidth during initial headers sync when a block is found
<bitcoin-git>
bitcoin/master f6a9166 Suhas Daftuar: Add functional test for block announcements during initial headers sync
<bitcoin-git>
bitcoin/master 22d96d7 Andrew Chow: Merge bitcoin/bitcoin#25720: p2p: Reduce bandwidth during initial headers ...
<bitcoin-git>
[bitcoin] achow101 merged pull request #25720: p2p: Reduce bandwidth during initial headers sync when a block is found (master...2022-07-reduce-headers-sync-bandwidth) https://github.com/bitcoin/bitcoin/pull/25720
cryptapus has quit [Quit: Konversation terminated!]
AaronvanW has quit [Remote host closed the connection]
<sipa>
_aj_: Hmm, interesting.
sipsorcery has quit [Ping timeout: 248 seconds]
<_aj_>
sipa: so maybe i am seeing it happen at the double height inflection point; but it still makes no sense to me why you'd switch to redownloading instead of just feeding the already validated headers through the logic
<sipa>
_aj_: Ah, yes, there I agree. That's what I referred to as "moving the starting point forward" in my earlier message. That's definitely better, but it's somewhat complicated to do right.
<_aj_>
sipa: i don't think you need to move the starting point forward; just pass the skipped headers through as if the peer had sent them to you
darosior has quit [Read error: Connection reset by peer]
darosior has joined #bitcoin-core-dev
_andrewtoth_ has joined #bitcoin-core-dev
andrewtoth_ has quit [Ping timeout: 268 seconds]
<sipa>
Ah, that is equivalent to one of the instances of moving the starting point forward, but restricted to redownloading.
<_aj_>
sipa: well it's moving progress forward, not the starting point per se (m_chain_start is left alone)
<sipa>
Right, during redownload the starting point doesn't actually matter anymore.
<sipa>
In the logic I was working on, I also did something similar during the initial phase.
<sipa>
Where it'd move the start point forward, which causes the redownload to start further ahead.
<sipa>
Maybe that's not actually useful? You'll detect it when redownload starts anyway.
AaronvanW has joined #bitcoin-core-dev
<sipa>
So just to be clear about what this gains us.
<sipa>
I believe it is just this: by skipping ahead more work, it increases the chance that the peer will overtake whatever other sync peers we have (possibly none, if there was one that was further ahead, but disconnected), shortening the time it takes to reach sync.
<sipa>
If the "tip peer" isn't overtaken, it has no real impact, as it wouldn't shorten the time it takes to reach minchainwork, so we'll keep syncing for all the same peers, for all the same time.
<sipa>
Does that sound right?
ghost43_ has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
yanmaani has quit [Ping timeout: 268 seconds]
ghost43 has quit [Ping timeout: 268 seconds]
yanmaani has joined #bitcoin-core-dev
aleggg has quit [Ping timeout: 248 seconds]
<sipa>
Ok, reading your code more carefully, this does work different than what I had in mind.
<sipa>
This is comparing received headers against the accepted headers chain. What I was thinking of was comparing commitments against the accepted headers chain.
<sipa>
In your code, is the commitment check even needed? You're already checking the full hash.
vasild has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 268 seconds]
PaperSword has quit [Read error: Connection reset by peer]
<sipa>
Oh, no, you indeed need the commitments to verify that the start point you're jumping to is actually an ancestor of the commitments tip you had earlier, and not on a fork.
<sipa>
@_aj_ I'm a bit concerned that this may interfere with the ability to accept legitimate reorgs. If the peer switches to a different chain in between the two phases, forking off near the sync start point, there is a 1/8 or 1/16 probability that this new chain we receive matches the commitment bits we had earlier, which would cause it to be treated as a mismatching continuation later, rather than as a valid different chain.
<sipa>
I guess it would only be a one-time thing; a retry after that failure would work just fine.
<luke-jr>
is it intentional that the interfaces::Wallet stuff may have multiple instances per CWallet? was looking at hiding CWallet details from the RPC code, but idk if that's a good idea in this case