π¬ davidgumberg commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1707541879)
I think this is right, just wanted to make a note that I believe @mzumsande earlier [comment](https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509) is relevant here. Namely, that it's not necessary to check for freshness here if we cannot have fresh-but-not-dirty entries, and even if we could, I'm not sure why we wouldn't remove them from the cache in this instance. But I think this should be addressed by any revival of #18746.
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1707541879)
I think this is right, just wanted to make a note that I believe @mzumsande earlier [comment](https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509) is relevant here. Namely, that it's not necessary to check for freshness here if we cannot have fresh-but-not-dirty entries, and even if we could, I'm not sure why we wouldn't remove them from the cache in this instance. But I think this should be addressed by any revival of #18746.
π¬ mzumsande commented on pull request "p2p: For assumeutxo, download snapshot chain before background chain":
(https://github.com/bitcoin/bitcoin/pull/29519#issuecomment-2274027378)
> Is there another crash you were referring to? The first commit message says:
We'd also crash trying to reorg because this scenario is not handled.
I didn't mean an assert with that, just a shutdown with a fatal error. I tested this in a functional test, if I recall correctly the following happened:
After loading the snapshot, I would connect a peer with a higher-work tip branching off below the snapshot height. On master we'd download blocks from this peer, and as soon as we'd have a an
...
(https://github.com/bitcoin/bitcoin/pull/29519#issuecomment-2274027378)
> Is there another crash you were referring to? The first commit message says:
We'd also crash trying to reorg because this scenario is not handled.
I didn't mean an assert with that, just a shutdown with a fatal error. I tested this in a functional test, if I recall correctly the following happened:
After loading the snapshot, I would connect a peer with a higher-work tip branching off below the snapshot height. On master we'd download blocks from this peer, and as soon as we'd have a an
...
π¬ boring877 commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707579334)
why not just keep it ? why act like communist and remove things you desire ~
alot of data and infrastructure already on testnet3, why force people your own desires ~
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707579334)
why not just keep it ? why act like communist and remove things you desire ~
alot of data and infrastructure already on testnet3, why force people your own desires ~
π¬ boring877 commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707583093)
> @fjahr I guess because I feel it's hard to make concrete promises about something that far out. If we _know_ we will remove testnet3 in v30, we should just deprecate it in v28 already (including a `-deprecatedrpc` requirement), rather than saying it will be deprecated. If not, the best we can do is announce an intent that it will be removed in the future, without concrete timing.
what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old script
...
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707583093)
> @fjahr I guess because I feel it's hard to make concrete promises about something that far out. If we _know_ we will remove testnet3 in v30, we should just deprecate it in v28 already (including a `-deprecatedrpc` requirement), rather than saying it will be deprecated. If not, the best we can do is announce an intent that it will be removed in the future, without concrete timing.
what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old script
...
π¬ murchandamus commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707589818)
> what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old scripts thats been used ...
No worries, you can continue to use Testnet 3 as long as you desire. Itβs just not going to be supported by Bitcoin Core starting with some upcoming version.
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707589818)
> what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old scripts thats been used ...
No worries, you can continue to use Testnet 3 as long as you desire. Itβs just not going to be supported by Bitcoin Core starting with some upcoming version.
π¬ fjahr commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707596947)
> > @fjahr I guess because I feel it's hard to make concrete promises about something that far out. If we _know_ we will remove testnet3 in v30, we should just deprecate it in v28 already (including a `-deprecatedrpc` requirement), rather than saying it will be deprecated. If not, the best we can do is announce an intent that it will be removed in the future, without concrete timing.
>
> what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old
...
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707596947)
> > @fjahr I guess because I feel it's hard to make concrete promises about something that far out. If we _know_ we will remove testnet3 in v30, we should just deprecate it in v28 already (including a `-deprecatedrpc` requirement), rather than saying it will be deprecated. If not, the best we can do is announce an intent that it will be removed in the future, without concrete timing.
>
> what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old
...
β
vostrnad closed a pull request: "Add a `-permitbarepubkey` option"
(https://github.com/bitcoin/bitcoin/pull/29309)
(https://github.com/bitcoin/bitcoin/pull/29309)
π¬ ariard commented on pull request "[27.x] Even more backports":
(https://github.com/bitcoin/bitcoin/pull/30558#issuecomment-2274085829)
@petertodd, Yeah it might be too much zeal, yet Iβve been surprised when the option was introduced with `24.x` how much services were still claiming to rely zero-conf acceptance. Same, Iβm not aware of any bitcoin industry traffic with real-traffic actually accepting unconfirmed transactions (apart of few LSPs with zero-conf, itβs a paradigm of its own and people running that are more savvy about unconf txn risks due to channel funding flow).
The proposed alternative wording βBitcoin Core rem
...
(https://github.com/bitcoin/bitcoin/pull/30558#issuecomment-2274085829)
@petertodd, Yeah it might be too much zeal, yet Iβve been surprised when the option was introduced with `24.x` how much services were still claiming to rely zero-conf acceptance. Same, Iβm not aware of any bitcoin industry traffic with real-traffic actually accepting unconfirmed transactions (apart of few LSPs with zero-conf, itβs a paradigm of its own and people running that are more savvy about unconf txn risks due to channel funding flow).
The proposed alternative wording βBitcoin Core rem
...
π€ ryanofsky reviewed a pull request: "kernel, refactor: return error status on all fatal errors"
(https://github.com/bitcoin/bitcoin/pull/29700#pullrequestreview-2225894783)
Rebased e22926a383223b286fe97a12ea4efaa81414bb41 -> 3ab9a46ac67964c9d5ad54120b680b5eee7f16f0 ([`pr/fatalresult.20`](https://github.com/ryanofsky/bitcoin/commits/pr/fatalresult.20) -> [`pr/fatalresult.21`](https://github.com/ryanofsky/bitcoin/commits/pr/fatalresult.21), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/fatalresult.20-rebase..pr/fatalresult.21)) due to conflicts with #30517 and #30497
(https://github.com/bitcoin/bitcoin/pull/29700#pullrequestreview-2225894783)
Rebased e22926a383223b286fe97a12ea4efaa81414bb41 -> 3ab9a46ac67964c9d5ad54120b680b5eee7f16f0 ([`pr/fatalresult.20`](https://github.com/ryanofsky/bitcoin/commits/pr/fatalresult.20) -> [`pr/fatalresult.21`](https://github.com/ryanofsky/bitcoin/commits/pr/fatalresult.21), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/fatalresult.20-rebase..pr/fatalresult.21)) due to conflicts with #30517 and #30497
π¬ ryanofsky commented on pull request "kernel, refactor: return error status on all fatal errors":
(https://github.com/bitcoin/bitcoin/pull/29700#discussion_r1707623223)
re: https://github.com/bitcoin/bitcoin/pull/29700#discussion_r1693183422
> Seems fragile to use `util::Result<InterruptResult>`. Wrapping one result into another is fragile, because call-sites may easily forget to unwrap the inner result, especially if the inner result is otherwise `void`. My recommendation would be to treat interruption as `util::Error`, so that callers don't miss it if they check for errors (but forget to check for interruption), but are free to check it, if they inspect th
...
(https://github.com/bitcoin/bitcoin/pull/29700#discussion_r1707623223)
re: https://github.com/bitcoin/bitcoin/pull/29700#discussion_r1693183422
> Seems fragile to use `util::Result<InterruptResult>`. Wrapping one result into another is fragile, because call-sites may easily forget to unwrap the inner result, especially if the inner result is otherwise `void`. My recommendation would be to treat interruption as `util::Error`, so that callers don't miss it if they check for errors (but forget to check for interruption), but are free to check it, if they inspect th
...
π¬ Retropex commented on pull request "Add a `-permitbarepubkey` option":
(https://github.com/bitcoin/bitcoin/pull/29309#issuecomment-2274112090)
Why closing this? @vostrnad
(https://github.com/bitcoin/bitcoin/pull/29309#issuecomment-2274112090)
Why closing this? @vostrnad
π¬ ariard commented on pull request "Remove mempoolfullrbf":
(https://github.com/bitcoin/bitcoin/pull/30592#issuecomment-2274116264)
@petertodd On the lightning side, in a world where as a node you have a scarcity of UTXO to allocate seeing locally a record of transaction-relay policy and consensus transaction, itβs very useful to start to have (unsafe indeed) HTLC flowing or fee-bump the transaction to increase funds velocity.
Iβm not insisting on keeping `mempoolfullrbf`. Itβs more very likely that your first-seen log of transaction to monitor double-spend will ressemble an in-_memory_ pool of transactions and as your co
...
(https://github.com/bitcoin/bitcoin/pull/30592#issuecomment-2274116264)
@petertodd On the lightning side, in a world where as a node you have a scarcity of UTXO to allocate seeing locally a record of transaction-relay policy and consensus transaction, itβs very useful to start to have (unsafe indeed) HTLC flowing or fee-bump the transaction to increase funds velocity.
Iβm not insisting on keeping `mempoolfullrbf`. Itβs more very likely that your first-seen log of transaction to monitor double-spend will ressemble an in-_memory_ pool of transactions and as your co
...
π¬ vostrnad commented on pull request "Add a `-permitbarepubkey` option":
(https://github.com/bitcoin/bitcoin/pull/29309#issuecomment-2274129837)
@Retropex I've rebased this enough times already for something I don't really think should be merged. Also I suspect anyone interested in this option has already switched to Knots anyway (which has it implemented).
(https://github.com/bitcoin/bitcoin/pull/29309#issuecomment-2274129837)
@Retropex I've rebased this enough times already for something I don't really think should be merged. Also I suspect anyone interested in this option has already switched to Knots anyway (which has it implemented).
π¬ pinheadmz commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707675544)
@boring877 Your comments are off topic and inflammatory, resulting in a 24 ban from the organization to cool off. I'm not going to delete your comments since this PR is closed anyway, and contributors offered informational replies. To appeal a moderation decision, open an issue in bitcoin-core/meta
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707675544)
@boring877 Your comments are off topic and inflammatory, resulting in a 24 ban from the organization to cool off. I'm not going to delete your comments since this PR is closed anyway, and contributors offered informational replies. To appeal a moderation decision, open an issue in bitcoin-core/meta
π glozow merged a pull request: "refactor: use recommended type hiding on multi_index types"
(https://github.com/bitcoin/bitcoin/pull/30194)
(https://github.com/bitcoin/bitcoin/pull/30194)
π¬ naiyoma commented on pull request "test: update satoshi_round function":
(https://github.com/bitcoin/bitcoin/pull/29566#issuecomment-2274153740)
> The pull request description will need to be updated to reflect the current state.
@maflcko Description updated. Also, reverted `fee_increment` to a float and then applied satoshi_round with ROUND_DOWN at the call site. This is much cleaner and more readable.
(https://github.com/bitcoin/bitcoin/pull/29566#issuecomment-2274153740)
> The pull request description will need to be updated to reflect the current state.
@maflcko Description updated. Also, reverted `fee_increment` to a float and then applied satoshi_round with ROUND_DOWN at the call site. This is much cleaner and more readable.
π€ Shuhaib07 reviewed a pull request: "crypto, refactor: add new KeyPair class"
(https://github.com/bitcoin/bitcoin/pull/30051#pullrequestreview-2225978666)
Okay
(https://github.com/bitcoin/bitcoin/pull/30051#pullrequestreview-2225978666)
Okay
π¬ brunoerg commented on issue "fuzz: crypto_fschacha20poly1305 timeout":
(https://github.com/bitcoin/bitcoin/issues/30505#issuecomment-2274161098)
What is the timeout value in OSS-Fuzz?
(https://github.com/bitcoin/bitcoin/issues/30505#issuecomment-2274161098)
What is the timeout value in OSS-Fuzz?
π¬ justinvforvendetta commented on pull request "get miniupnpc from ssl, this reverts commit 21b8a14d37c19ce292d5529597e0d52338db48a9":
(https://github.com/bitcoin/bitcoin/pull/30564#issuecomment-2274168843)
@willcl-ark fixed it. i misinterpreted, thanks
(https://github.com/bitcoin/bitcoin/pull/30564#issuecomment-2274168843)
@willcl-ark fixed it. i misinterpreted, thanks
π¬ hebasto commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1707716090)
Thanks! Implemented in https://github.com/hebasto/bitcoin/pull/313.
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1707716090)
Thanks! Implemented in https://github.com/hebasto/bitcoin/pull/313.