💬 fanquake commented on pull request "Update chainparams for 25.x":
(https://github.com/bitcoin/bitcoin/pull/27223#issuecomment-1512884770)
Done in #27482 (added you as co-author).
(https://github.com/bitcoin/bitcoin/pull/27223#issuecomment-1512884770)
Done in #27482 (added you as co-author).
📝 MarcoFalke opened a pull request: " Bump python minimum version to 3.8 "
(https://github.com/bitcoin/bitcoin/pull/27483)
There is no pressing reason to drop support for 3.7, however there are several maintenance issues:
* There is no supported operating system that ships 3.7 by default. (debian:buster is EOL and unmaintained to the extent that it doesn't run in the CI environment. See https://github.com/bitcoin/bitcoin/pull/27340#issuecomment-1484988445)
* Compiling python 3.7 from source is also unsupported on at least macos, according to https://github.com/bitcoin/bitcoin/pull/24017#issuecomment-1107820790
...
(https://github.com/bitcoin/bitcoin/pull/27483)
There is no pressing reason to drop support for 3.7, however there are several maintenance issues:
* There is no supported operating system that ships 3.7 by default. (debian:buster is EOL and unmaintained to the extent that it doesn't run in the CI environment. See https://github.com/bitcoin/bitcoin/pull/27340#issuecomment-1484988445)
* Compiling python 3.7 from source is also unsupported on at least macos, according to https://github.com/bitcoin/bitcoin/pull/24017#issuecomment-1107820790
...
💬 fanquake commented on pull request "[24.x] Additional backports for 24.1":
(https://github.com/bitcoin/bitcoin/pull/27474#issuecomment-1512916261)
> Suggest adding https://github.com/stickies-v/bitcoin/commit/db6cf79694112a4679378fdd1f2bdf69cf6adbea which backports https://github.com/bitcoin/bitcoin/pull/27468,
Pulled & added metadata.
> Suggest adding https://github.com/bitcoin/bitcoin/commit/f73782a9032a462a71569e9424db9bf9eeababf3.
Ok.
(https://github.com/bitcoin/bitcoin/pull/27474#issuecomment-1512916261)
> Suggest adding https://github.com/stickies-v/bitcoin/commit/db6cf79694112a4679378fdd1f2bdf69cf6adbea which backports https://github.com/bitcoin/bitcoin/pull/27468,
Pulled & added metadata.
> Suggest adding https://github.com/bitcoin/bitcoin/commit/f73782a9032a462a71569e9424db9bf9eeababf3.
Ok.
💬 darosior commented on pull request "Remove BIP35 mempool p2p message":
(https://github.com/bitcoin/bitcoin/pull/27426#issuecomment-1512920984)
Concept ACK but i think BTCPay is using it. cc @NicolasDorier
(https://github.com/bitcoin/bitcoin/pull/27426#issuecomment-1512920984)
Concept ACK but i think BTCPay is using it. cc @NicolasDorier
📝 fanquake opened a pull request: "doc: remove outdated version number usage from release-process"
(https://github.com/bitcoin/bitcoin/pull/27484)
We no-longer use the leading `0.` version number, and having a mixture is both in the release-process examples is needlessly confusing.
(https://github.com/bitcoin/bitcoin/pull/27484)
We no-longer use the leading `0.` version number, and having a mixture is both in the release-process examples is needlessly confusing.
🤔 stickies-v reviewed a pull request: "Bump python minimum version to 3.8"
(https://github.com/bitcoin/bitcoin/pull/27483#pullrequestreview-1389896117)
Concept ACK
I'm not sure why we're switching to focal instead of bullseye for the `qt5` ci, but I don't really have a view either way. Just pointing it out.
(https://github.com/bitcoin/bitcoin/pull/27483#pullrequestreview-1389896117)
Concept ACK
I'm not sure why we're switching to focal instead of bullseye for the `qt5` ci, but I don't really have a view either way. Just pointing it out.
💬 stickies-v commented on pull request "Bump python minimum version to 3.8":
(https://github.com/bitcoin/bitcoin/pull/27483#discussion_r1169893585)
```suggestion
| [Python](https://www.python.org) (scripts, tests) | [3.8](https://github.com/bitcoin/bitcoin/pull/27483) |
```
(https://github.com/bitcoin/bitcoin/pull/27483#discussion_r1169893585)
```suggestion
| [Python](https://www.python.org) (scripts, tests) | [3.8](https://github.com/bitcoin/bitcoin/pull/27483) |
```
💬 MarcoFalke commented on pull request "Bump python minimum version to 3.8":
(https://github.com/bitcoin/bitcoin/pull/27483#issuecomment-1512944734)
> I'm not sure why we're switching to focal instead of bullseye
The reason is that bullseye does not have a single of the needed packages:
* https://packages.debian.org/bullseye/g++-8
* https://packages.debian.org/bullseye/clang-8
* https://packages.debian.org/bullseye/python3
(https://github.com/bitcoin/bitcoin/pull/27483#issuecomment-1512944734)
> I'm not sure why we're switching to focal instead of bullseye
The reason is that bullseye does not have a single of the needed packages:
* https://packages.debian.org/bullseye/g++-8
* https://packages.debian.org/bullseye/clang-8
* https://packages.debian.org/bullseye/python3
💬 furszy commented on pull request "wallet: bugfix, 'AvailableCoins' invalid output type set for raw PK outputs":
(https://github.com/bitcoin/bitcoin/pull/27478#issuecomment-1513020966)
closing since it's not a bug, just an odd classification.
(https://github.com/bitcoin/bitcoin/pull/27478#issuecomment-1513020966)
closing since it's not a bug, just an odd classification.
✅ furszy closed a pull request: "wallet: bugfix, 'AvailableCoins' invalid output type set for raw PK outputs"
(https://github.com/bitcoin/bitcoin/pull/27478)
(https://github.com/bitcoin/bitcoin/pull/27478)
💬 fanquake commented on pull request "Bump python minimum version to 3.8":
(https://github.com/bitcoin/bitcoin/pull/27483#issuecomment-1513082712)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/27483#issuecomment-1513082712)
Concept ACK
💬 MarcoFalke commented on pull request "Bump python minimum version to 3.8":
(https://github.com/bitcoin/bitcoin/pull/27483#discussion_r1170005753)
thx, done
(https://github.com/bitcoin/bitcoin/pull/27483#discussion_r1170005753)
thx, done
👍 stickies-v approved a pull request: "doc: remove outdated version number usage from release-process"
(https://github.com/bitcoin/bitcoin/pull/27484#pullrequestreview-1390113171)
ACK fde224a6610699a6a28cc27e299ac14cbf7e16ca
Couldn't find any other outdated examples.
(https://github.com/bitcoin/bitcoin/pull/27484#pullrequestreview-1390113171)
ACK fde224a6610699a6a28cc27e299ac14cbf7e16ca
Couldn't find any other outdated examples.
📝 fanquake opened a pull request: "[WIP] ci: standardize custom libc++ usage in MSAN jobs"
(https://github.com/bitcoin/bitcoin/pull/27485)
Use `-isystem` & `-nostd*` flags, which is the preferred way to use a custom libc++ (ours is libc++ build with MSAN) with Clang, as opposed to our current ad-hoc flags.
See: https://releases.llvm.org/16.0.0/projects/libcxx/docs/UsingLibcxx.html#using-a-custom-built-libc for more info:
> Most compilers provide a way to disable the default behavior for finding the standard library and to override it with custom paths. With Clang, this can be done with:
```bash
clang++ -nostdinc++ -nostdlib++
...
(https://github.com/bitcoin/bitcoin/pull/27485)
Use `-isystem` & `-nostd*` flags, which is the preferred way to use a custom libc++ (ours is libc++ build with MSAN) with Clang, as opposed to our current ad-hoc flags.
See: https://releases.llvm.org/16.0.0/projects/libcxx/docs/UsingLibcxx.html#using-a-custom-built-libc for more info:
> Most compilers provide a way to disable the default behavior for finding the standard library and to override it with custom paths. With Clang, this can be done with:
```bash
clang++ -nostdinc++ -nostdlib++
...
💬 0xB10C commented on pull request "doc: remove outdated version number usage from release-process":
(https://github.com/bitcoin/bitcoin/pull/27484#issuecomment-1513170888)
ACK
(https://github.com/bitcoin/bitcoin/pull/27484#issuecomment-1513170888)
ACK
💬 jnewbery commented on pull request "p2p: Track orphans by who provided them":
(https://github.com/bitcoin/bitcoin/pull/26551#discussion_r1170060171)
> should we move orphan processing outside of ProcessMessages and SendMessages entirely, and just do it separately, independent of both who sent the orphan and who sent the parent?
>
> Unless someone has a good reason not to, I think I might draft that up as an alternative PR so the approaches can be compared more directly.
See #19364
(https://github.com/bitcoin/bitcoin/pull/26551#discussion_r1170060171)
> should we move orphan processing outside of ProcessMessages and SendMessages entirely, and just do it separately, independent of both who sent the orphan and who sent the parent?
>
> Unless someone has a good reason not to, I think I might draft that up as an alternative PR so the approaches can be compared more directly.
See #19364
💬 furszy commented on pull request "wallet: improve IBD sync time by skipping block scanning prior birth time":
(https://github.com/bitcoin/bitcoin/pull/27469#discussion_r1170062170)
Mainly to be consistent with the chain interface, wallet and spkm sources. Timestamps are represented as `int64_t` there. E.g. the `FoundBlock` class, `findFirstBlockWithTimeAndHeight` method, the `CWallet::m_best_block_time` member, first key time, descriptor creation time etc.
I think that is clear that block times are always in seconds, so the use of an arithmetic type shouldn't be much of a worry but we could switch all of them to `NodeSeconds` too (probably in another PR that does it all
...
(https://github.com/bitcoin/bitcoin/pull/27469#discussion_r1170062170)
Mainly to be consistent with the chain interface, wallet and spkm sources. Timestamps are represented as `int64_t` there. E.g. the `FoundBlock` class, `findFirstBlockWithTimeAndHeight` method, the `CWallet::m_best_block_time` member, first key time, descriptor creation time etc.
I think that is clear that block times are always in seconds, so the use of an arithmetic type shouldn't be much of a worry but we could switch all of them to `NodeSeconds` too (probably in another PR that does it all
...
👍 stickies-v approved a pull request: "[24.x] Additional backports for 24.1"
(https://github.com/bitcoin/bitcoin/pull/27474#pullrequestreview-1390158761)
ACK dc711fbd32653b09e196f72942106114a32353f4
Verified that the backports correspond to their original PR, and I can't see any silent merge conflicts. Release notes match the backported changes.
(https://github.com/bitcoin/bitcoin/pull/27474#pullrequestreview-1390158761)
ACK dc711fbd32653b09e196f72942106114a32353f4
Verified that the backports correspond to their original PR, and I can't see any silent merge conflicts. Release notes match the backported changes.
💬 rebroad commented on issue "add ability to remove (dust) UTXOs":
(https://github.com/bitcoin/bitcoin/issues/23875#issuecomment-1513184940)

I do think there's an unforeseen cost in storing these dust UTXOs, which might result in people willing to pay into a pot to have them cleared up - a bit like people grouping together to clean up the beaches of litter. If people didn't have to pay to pick-up their own dust, then it dust-picking might occur more often.
(https://github.com/bitcoin/bitcoin/issues/23875#issuecomment-1513184940)

I do think there's an unforeseen cost in storing these dust UTXOs, which might result in people willing to pay into a pot to have them cleared up - a bit like people grouping together to clean up the beaches of litter. If people didn't have to pay to pick-up their own dust, then it dust-picking might occur more often.
💬 0xB10C commented on pull request "kernel: chainparams updates for 25.x":
(https://github.com/bitcoin/bitcoin/pull/27482#discussion_r1170066121)
2429000 on testnet might be too recent according to the docs: "Testnet should be set with a height some tens of thousands back from the tip, due to reorgs there.". It's currently 428 blocks old. There are still frequent [reorgs on testnet](https://fork.observer/?network=2), with the youngest being at 2428585. However, most reorgs on testnet I've seen are one-block reorgs and wouldn't affect this.
(https://github.com/bitcoin/bitcoin/pull/27482#discussion_r1170066121)
2429000 on testnet might be too recent according to the docs: "Testnet should be set with a height some tens of thousands back from the tip, due to reorgs there.". It's currently 428 blocks old. There are still frequent [reorgs on testnet](https://fork.observer/?network=2), with the youngest being at 2428585. However, most reorgs on testnet I've seen are one-block reorgs and wouldn't affect this.