💬 fanquake commented on issue "make check errors on big endian OpenBSD 7.2":
(https://github.com/bitcoin/bitcoin/issues/26492#issuecomment-1453413473)
Added to the 25.x milestone. Let's get this sorted out by the release.

💬 TheCharlatan commented on pull request "blockstorage: add an assert to avoid running oom with `-fastprune`":
(https://github.com/bitcoin/bitcoin/pull/27191#issuecomment-1453440605)
Not sure how I feel about this change. It is trivial to create blocks exceeding this limit on regtest. If this happens, it should at least log a message explaining why it failed. The size limit constants used by fastprune seem arbitrary to me. What is their rationale, just fewer resources allocated while testing? If so, why are the revision files not size restricted as well?

💬 ryanofsky commented on pull request "refactor: Use move semantics instead of custom swap functions":
(https://github.com/bitcoin/bitcoin/pull/26749#discussion_r1124429747)
> > Should this use emplace_back instead of push_back?
>
> I didn't mention this because I assumed the two functions would do the same if they received a moved object that is already fully constructed?

Oh, I think you are right they are equivalent in this case. I still think it would be a little better to use emplace_back for readability though, because with emplace_back you can be sure object is being constructed directly, while with push_back you have to check the types to know if a temp
...

💬 dougEfresh commented on pull request "doc: Fixup remove 'omitted...' doc for rpc getrawtransaction when verbose is 2":
(https://github.com/bitcoin/bitcoin/pull/26968#issuecomment-1453532752)
@stickies-v This better?

💬 stickies-v commented on pull request "doc: Fixup remove 'omitted...' doc for rpc getrawtransaction when verbose is 2":
(https://github.com/bitcoin/bitcoin/pull/26968#discussion_r1124508727)
@dougEfresh this seems unaddressed?

💬 stickies-v commented on pull request "doc: Fixup remove 'omitted...' doc for rpc getrawtransaction when verbose is 2":
(https://github.com/bitcoin/bitcoin/pull/26968#discussion_r1124508846)
@dougEfresh this seems unaddressed?

💬 MarcoFalke commented on issue "Feature request: alert PR author in case of CI failure":
(https://github.com/bitcoin/bitcoin/issues/27178#issuecomment-1453594425)
Some more notes:

* I think we don't want to send out notifications for each failed task, only one if any task failed.

So what about adding a new label (yes moar labels) "CI failed" (or so) with the same process as "Needs rebase"? This would notify ~everyone, not only the author, but I think this is what we want. Because notifying the author in case of a intermittent CI network error is entirely pointless if they can't re-run the task anyway. For example, I can't re-run tasks anymore, so se
...

💬 fanquake commented on issue "-march=armv8-a+crc+crypto detected as "yes" on ppc64 clang":
(https://github.com/bitcoin/bitcoin/issues/26025#issuecomment-1453602966)
Going to close this for now, as there isn't really anything here for us to do. Upstream now has a change open to fix the problem: https://reviews.llvm.org/D145141, that should land in LLVM/Clang 17.x.

✅ fanquake closed an issue: "-march=armv8-a+crc+crypto detected as "yes" on ppc64 clang"
(https://github.com/bitcoin/bitcoin/issues/26025)

💬 fanquake commented on issue "Disallow duplicate leaves inside `tr()` descriptors":
(https://github.com/bitcoin/bitcoin/issues/27104#issuecomment-1453604654)
Also cc @instagibbs (don't see any reaction)

🚀 fanquake merged a pull request: "refactor: RPC: pass named argument value as string_view"
(https://github.com/bitcoin/bitcoin/pull/26612)

👋 fanquake's pull request is ready for review: "build: produce a .zip for macOS distribution"
(https://github.com/bitcoin/bitcoin/pull/27099)

💬 fanquake commented on pull request "build: produce a .zip for macOS distribution":
(https://github.com/bitcoin/bitcoin/pull/27099#issuecomment-1453621303)
A few Concept ACKs here, so have rebased and undrafted.

💬 fanquake commented on pull request "refactor: RPC: pass named argument value as string_view":
(https://github.com/bitcoin/bitcoin/pull/26612#issuecomment-1453623741)
> I think the followup ideas in the PR description sound very good too

@stickies-v will you follow up here?

📝 furszy opened a pull request: "bumpfee: allow send coins back to yourself"
(https://github.com/bitcoin/bitcoin/pull/27195)
Simple example:

1) User_1 sends 0.1 btc to user_2 on a low fee transaction.
2) After few hours, the tx is still in the mempool, user_2
is not interested anymore, so user_1 decides to cancel
it by sending coins back to himself.
3) User_1 has the bright idea of opening the explorer and
copy the change output address of the transaction. Then
call bumpfee providing such output (in the "outputs" arg).

Currently, this is not possible. The wallet fails with
"Unable to create tr
...

💬 furszy commented on pull request "bumpfee: Allow the user to choose which output is change":
(https://github.com/bitcoin/bitcoin/pull/26467#discussion_r1124613138)
This is not contemplating the user changing the outputs for a single change output. E.g. bump tx to send coins back to yourself.

The generated `temp_mtx` uses the same outputs as the previous transaction, so the provided output is discarded. And only deduces the new fee from the previous tx outputs.

Previously, in master, we would just fail on this situation. While here, we return a tx that is not what the user wants.
So, created #27195 to solve the issue in master first.

💬 kristapsk commented on pull request "bumpfee: allow send coins back to yourself":
(https://github.com/bitcoin/bitcoin/pull/27195#issuecomment-1453704911)
Not the scope of this PR, but related - in GUI this should be implemented as another context menu item "Cancel transaction".

💬 mzumsande commented on pull request "blockstorage: add an assert to avoid running oom with `-fastprune`":
(https://github.com/bitcoin/bitcoin/pull/27191#issuecomment-1453807035)
> Not sure how I feel about this change. It is trivial to create blocks exceeding this limit on regtest. If this happens, it should at least log a message explaining why it failed.

I'll add a log message with my next push.

> The size limit constants used by fastprune seem arbitrary to me. What is their rationale, just fewer resources allocated/used while running the pruning functional tests? If so, why are the revision files not size restricted as well?

It was introduced in c286a22f7b63
...

💬 1440000bytes commented on pull request "bumpfee: allow send coins back to yourself":
(https://github.com/bitcoin/bitcoin/pull/27195#issuecomment-1453858419)
We will need approval from @achow101 and @murch

💬 brunoerg commented on pull request "assumeutxo: background validation completion":
(https://github.com/bitcoin/bitcoin/pull/25740#issuecomment-1453928410)
> The commit message of https://github.com/bitcoin/bitcoin/commit/287bb3f4ce41341aa0aea97b8176dc790889830d "validation: add CChainState::m_disabled and ChainMan::isUsable" still mentions m_stop_use rather than m_disabled

In the pull description, it still mention `m_stop_use`.