💬 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.
(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)
(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)
(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)
(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)
(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.
(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?
(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
...
(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.
(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".
(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
...
(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
(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`.
(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`.
💬 stratospher commented on pull request "p2p: Prevent block index fingerprinting by sending additional getheaders messages":
(https://github.com/bitcoin/bitcoin/pull/24571#discussion_r1124917812)
did i understand this correctly? - `UpdateChainTipSet` updates chain tip set based on:
1. the whole block/valid headers we received and were told of from other nodes on the same network
2. when we switch networks, chain tip set initially would only contain [tip of active chain.](https://github.com/bitcoin/bitcoin/blob/86f19bdab78c09a124b15e2d4a72439f13281999/src/net_processing.cpp#L2653)
3. inbound and outbound connections on same network would have different chain tip set. is th
...
(https://github.com/bitcoin/bitcoin/pull/24571#discussion_r1124917812)
did i understand this correctly? - `UpdateChainTipSet` updates chain tip set based on:
1. the whole block/valid headers we received and were told of from other nodes on the same network
2. when we switch networks, chain tip set initially would only contain [tip of active chain.](https://github.com/bitcoin/bitcoin/blob/86f19bdab78c09a124b15e2d4a72439f13281999/src/net_processing.cpp#L2653)
3. inbound and outbound connections on same network would have different chain tip set. is th
...
💬 stratospher commented on pull request "p2p: Prevent block index fingerprinting by sending additional getheaders messages":
(https://github.com/bitcoin/bitcoin/pull/24571#discussion_r1124920540)
`IsAncestorOfBestHeaderOrTip` would already by contained in `IsBlockInChainTipSet` right? do we include `IsAncestorOfBestHeaderOrTip` check for performance gain instead of iterating over all the chain tips? or is there some other reason?
(https://github.com/bitcoin/bitcoin/pull/24571#discussion_r1124920540)
`IsAncestorOfBestHeaderOrTip` would already by contained in `IsBlockInChainTipSet` right? do we include `IsAncestorOfBestHeaderOrTip` check for performance gain instead of iterating over all the chain tips? or is there some other reason?
💬 adamjonas commented on issue "estimatesmartfee returns 50 sat/vB on an empty mempool for inclusion in 1008 blocks":
(https://github.com/bitcoin/bitcoin/issues/26304#issuecomment-1454129097)
> I don't think anything can be done here
This appears to be something that isn't going to be picked up in the near future.
(https://github.com/bitcoin/bitcoin/issues/26304#issuecomment-1454129097)
> I don't think anything can be done here
This appears to be something that isn't going to be picked up in the near future.
✅ adamjonas closed an issue: "estimatesmartfee returns 50 sat/vB on an empty mempool for inclusion in 1008 blocks"
(https://github.com/bitcoin/bitcoin/issues/26304)
(https://github.com/bitcoin/bitcoin/issues/26304)
💬 pinheadmz commented on issue "Versionbits should have an ignore button":
(https://github.com/bitcoin/bitcoin/issues/8266#issuecomment-1454132480)
I think this issue can be closed since the warnings were removed in https://github.com/bitcoin/bitcoin/pull/15471
(https://github.com/bitcoin/bitcoin/issues/8266#issuecomment-1454132480)
I think this issue can be closed since the warnings were removed in https://github.com/bitcoin/bitcoin/pull/15471
👍 brunoerg approved a pull request: "assumeutxo: background validation completion"
(https://github.com/bitcoin/bitcoin/pull/25740)
crACK a00d0e78510d79bc9fc57ec622aec98a65efa8c0
In 5ee22cdafd2562bcb8bf0ae6025e4b53c826382d, it creates `ChainstateManager::GetSnapshotBaseBlock` and `ChainstateManager::GetSnapshotBaseHeight`. `GetSnapshotBaseHeight` is used (not in this commit) in `MaybeCompleteSnapshotValidation` to check if IBD (_in background_) has been completed.
In c29f26b47b8ef978d8689dc0222aa663361ee6cb, it creates `CChainState::m_disabled` and I could check it's been used to point that a chainstate should no long
...
(https://github.com/bitcoin/bitcoin/pull/25740)
crACK a00d0e78510d79bc9fc57ec622aec98a65efa8c0
In 5ee22cdafd2562bcb8bf0ae6025e4b53c826382d, it creates `ChainstateManager::GetSnapshotBaseBlock` and `ChainstateManager::GetSnapshotBaseHeight`. `GetSnapshotBaseHeight` is used (not in this commit) in `MaybeCompleteSnapshotValidation` to check if IBD (_in background_) has been completed.
In c29f26b47b8ef978d8689dc0222aa663361ee6cb, it creates `CChainState::m_disabled` and I could check it's been used to point that a chainstate should no long
...
💬 pinheadmz commented on issue "Adoption of BIP39/44/49/84, and classification of (extended) pub/priv keys, addresses, mnemonics, etc":
(https://github.com/bitcoin/bitcoin/issues/17748#issuecomment-1454140876)
I think this issue has been solved by descriptor wallets. We can keep open #19151 for more discussion about using BIP39 in Bitcoin Core
(https://github.com/bitcoin/bitcoin/issues/17748#issuecomment-1454140876)
I think this issue has been solved by descriptor wallets. We can keep open #19151 for more discussion about using BIP39 in Bitcoin Core