<bitcoin-git>
gui-qml/main 4dea7c9 pablomartin4btc: qml, proxy: Allow IPv6 and move out UI validation
<bitcoin-git>
gui-qml/main 765f608 Hennadii Stepanov: Merge bitcoin-core/gui-qml#430: Allow IPv6 in Proxy settings and moving va...
<bitcoin-git>
[gui-qml] hebasto merged pull request #430: Allow IPv6 in Proxy settings and moving validation out from the UI into the model/ interface (main...qml-ipaddress-allow-ipv6) https://github.com/bitcoin-core/gui-qml/pull/430
pyth has quit [Remote host closed the connection]
pyth has joined #bitcoin-core-dev
PaperSword has quit [Quit: PaperSword]
BrandonOdiwuor has quit [Ping timeout: 240 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 245 seconds]
eval-exec has quit [Remote host closed the connection]
abubakarsadiq has joined #bitcoin-core-dev
eval-exec has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
eval-exec has quit [Ping timeout: 260 seconds]
flooded is now known as _flood
jonatack has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] kevkevinpal opened pull request #31784: test: added additional coverage to waitforblock and waitforblockheight rpc's (master...moreTimeoutTests) https://github.com/bitcoin/bitcoin/pull/31784
bitdex has quit [Quit: = ""]
zeropoint has joined #bitcoin-core-dev
thoragh has quit [Ping timeout: 245 seconds]
jespada has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
zeropoint has quit [Quit: leaving]
<bitcoin-git>
[bitcoin] Sjors opened pull request #31785: Have createNewBlock() ensure m_tip_block is set (master...2025/02/create_new_block) https://github.com/bitcoin/bitcoin/pull/31785
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
<bitcoin-git>
[gui] rhysbeynon opened pull request #852: Updated MacOS icon to more closely fit Apple's design standards (master...updated-icns) https://github.com/bitcoin-core/gui/pull/852
jonatack has joined #bitcoin-core-dev
mcey has joined #bitcoin-core-dev
Allanon has joined #bitcoin-core-dev
mcey_ has quit [Ping timeout: 244 seconds]
Allanon has quit [Client Quit]
jonatack has quit [Read error: Connection reset by peer]
<bitcoin-git>
[bitcoin] Sjors closed pull request #31763: Pass custom DEP_OPTS and CONFIG_FLAGS to guix-build (master...2025/01/guix-config-flags) https://github.com/bitcoin/bitcoin/pull/31763
zeropoint has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
luke-jr has joined #bitcoin-core-dev
rszarka has joined #bitcoin-core-dev
luke-jr_ has quit [Ping timeout: 244 seconds]
luke-jr has quit [Read error: Connection reset by peer]
Guyver2 has left #bitcoin-core-dev [Closing Window]
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jonatack has joined #bitcoin-core-dev
<darosior>
People who were around then, how did BIP113 deal with the upgrade issues mentioned in ConnectBlock? (It only check if a bad block wasn't let in using CheckBlock, not CtxCheckBlock[Header].) It seems the PR that implemented it only had a check in CtxCheckBlock() and none in ConnectBlock() so in theory an invalid block post-activation could have been
<darosior>
Another soft fork since the separation of CtxCheckBlock that introduced new rules there is Segwit. But for Segwit the RewindBlockIndex mechanism introduced in 6032f6930a56c107dad8f30c05fec4aab79c8c22 dealt with this.
<sipa>
darosior: we have generally never implemented a "check if old accepted blocks prior to a softfork are valid post-software"; the assumption is that the active main chain is the same before and after
<sipa>
for segwit things were different, because the serialization format changed, and it we needed to make sure that if someone upgraded to segwit after activation, they actually have the full block data available to serve to others
<sipa>
darosior: i don't see how the presence of a warning invalidates anything i said? :)
<darosior>
Fair enough :)
<sipa>
it's a concern for sure, but apart from segwit, we've never actually implemented re-validation of old softforks
<sipa>
to the best of my knowledge
<darosior>
Ok, thanks
<sipa>
hmm, perhaps the header-impacting aspects for BIP34, BIP65, and BIP66 (the fact that after 950 out of the past 1000 blocks signal, all blocks are required to signal) could be considered a re-validation aspect
<sipa>
i'm now somewhat curious what would have happened if you upgraded to BIP66 while you were on the forked chain that it caused
<darosior>
Wouldn't you just have marked the chain as invalid since the check happens in ConnectBlock() in the first place? (in scripts)
<sipa>
i *just* mean the header aspect
<sipa>
not the script validation rule
<sipa>
my thinking is that the first time you start up with BIP66-enforcing software, you'd have a chainstate whose tip points to a block whose headers chain is invalid, in this setting
<bitcoin-git>
[bitcoin] darosior opened pull request #31792: Double check all block rules in `ConnectBlock`, not only `CheckBlock` (master...2502_ctx_checks_in_connectblock) https://github.com/bitcoin/bitcoin/pull/31792
<darosior>
RFC ^
Talkless has quit [Quit: Konversation terminated!]
jonatack has quit [Read error: Connection reset by peer]
mcey has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
mcey has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
fearbeag has quit [Ping timeout: 252 seconds]
fearbeag has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
eugenesiegel has joined #bitcoin-core-dev
eugenesiegel has quit [Changing host]
eugenesiegel has joined #bitcoin-core-dev
<eugenesiegel>
Would anybody know why specifically v27.0 nodes would disconnect inbound connections for not writing after 30 seconds? It doesn't happen with other versions and it happens with quite a few nodes. I didn't see anything in the changelog about any sort of write timeout being changed and I don't see anywhere in the code where a 30 second timeout is
<eugenesiegel>
used. Additionally, if I write a spam message on the connection, the node doesn't disconnect me.
<sipa>
eugenesiegel: and this doesn't happen with 26.0?
<eugenesiegel>
I couldn't reproduce locally when I checked out v27.0. It doesn't happen with remote nodes on 26.0 or 28.0, only nodes on 27.0 from what I can tell. It's also about 800 of these 27.0 nodes