💬 jsarenik commented on issue "Memory-only wallet (for faucets)":
(https://github.com/bitcoin/bitcoin/issues/31816#issuecomment-2656886387)
Yes, @maflcko , it works well, I just need to unload the wallet, `echo 'VACUUM;' | sqlite3 wallet dat` and load it back.
I think the feature suggestion in this issue still makes sense though.
(https://github.com/bitcoin/bitcoin/issues/31816#issuecomment-2656886387)
Yes, @maflcko , it works well, I just need to unload the wallet, `echo 'VACUUM;' | sqlite3 wallet dat` and load it back.
I think the feature suggestion in this issue still makes sense though.
💬 sipa commented on issue "Wallet passpharse":
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656903312)
Without the ability to reproduce the problem, there is little that can be done.
Can you tell us a bit more about your set-up? The issue says you compiled it from source? Which compiler?
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656903312)
Without the ability to reproduce the problem, there is little that can be done.
Can you tell us a bit more about your set-up? The issue says you compiled it from source? Which compiler?
🤔 stickies-v reviewed a pull request: "Add -pruneduringinit option to temporarily use another prune target during IBD"
(https://github.com/bitcoin/bitcoin/pull/31845#pullrequestreview-2615366818)
> Can't we just do an IBD without pruning
Disabling pruning is only possible on devices with sufficient disk space, but I agree that a simple restart seems like an easy enough workaround if benchmarks indicate that this a worthwhile performance improvement:
```
bitcoind --prune=4000 --stopatheight={current_tip} && bitcoind --prune=300
```
Approach NACK, I don't think this needs a separate startup option. If benchmarks agree, I think a PR that improves the `--prune` documentation would
...
(https://github.com/bitcoin/bitcoin/pull/31845#pullrequestreview-2615366818)
> Can't we just do an IBD without pruning
Disabling pruning is only possible on devices with sufficient disk space, but I agree that a simple restart seems like an easy enough workaround if benchmarks indicate that this a worthwhile performance improvement:
```
bitcoind --prune=4000 --stopatheight={current_tip} && bitcoind --prune=300
```
Approach NACK, I don't think this needs a separate startup option. If benchmarks agree, I think a PR that improves the `--prune` documentation would
...
💬 InnDe commented on issue "Wallet passpharse":
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656918683)
I install the software from www.bitcoin.org
On Thu, 13 Feb 2025 at 18:10, Pieter Wuille ***@***.***>
wrote:
> Without the ability to reproduce the problem, there is little that can be
> done.
>
> Can you tell us a bit more about your set-up? The issue says you compiled
> it from source? Which compiler?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656903312>,
> or unsubscribe
> <https://github.com/notific
...
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656918683)
I install the software from www.bitcoin.org
On Thu, 13 Feb 2025 at 18:10, Pieter Wuille ***@***.***>
wrote:
> Without the ability to reproduce the problem, there is little that can be
> done.
>
> Can you tell us a bit more about your set-up? The issue says you compiled
> it from source? Which compiler?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656903312>,
> or unsubscribe
> <https://github.com/notific
...
💬 hebasto commented on pull request "depends: add missing Darwin objcopy":
(https://github.com/bitcoin/bitcoin/pull/31840#issuecomment-2656921804)
> Our CMake toolchain for a Darwin cross build currently contains:
>
> ```shell
> set(CMAKE_AR "/usr/bin/llvm-ar")
> set(CMAKE_RANLIB "/usr/bin/llvm-ranlib")
> set(CMAKE_STRIP "/usr/bin/llvm-strip")
> set(CMAKE_OBJCOPY "arm64-apple-darwin-objcopy")
> set(CMAKE_OBJDUMP "/usr/bin/llvm-objdump")
> ```
>
> `objcopy` isn't currently used for the Darwin build (only for Linux and splitting the debug symbols), but we shouldn't be producing a toolchain file that refers to nonexistent tools.
...
(https://github.com/bitcoin/bitcoin/pull/31840#issuecomment-2656921804)
> Our CMake toolchain for a Darwin cross build currently contains:
>
> ```shell
> set(CMAKE_AR "/usr/bin/llvm-ar")
> set(CMAKE_RANLIB "/usr/bin/llvm-ranlib")
> set(CMAKE_STRIP "/usr/bin/llvm-strip")
> set(CMAKE_OBJCOPY "arm64-apple-darwin-objcopy")
> set(CMAKE_OBJDUMP "/usr/bin/llvm-objdump")
> ```
>
> `objcopy` isn't currently used for the Darwin build (only for Linux and splitting the debug symbols), but we shouldn't be producing a toolchain file that refers to nonexistent tools.
...
🤔 rkrux reviewed a pull request: "wallet: abandon orphan coinbase txs, and their descendants, during startup"
(https://github.com/bitcoin/bitcoin/pull/31794#pullrequestreview-2615195468)
Cursory review, will look again soon
(https://github.com/bitcoin/bitcoin/pull/31794#pullrequestreview-2615195468)
Cursory review, will look again soon
💬 rkrux commented on pull request "wallet: abandon orphan coinbase txs, and their descendants, during startup":
(https://github.com/bitcoin/bitcoin/pull/31794#discussion_r1954619394)
`RecursiveUpdateTxState()` accepts a `const uint256& tx_hash` as the first argument but `tx.GetHash()` returns a `Txid&`, which is `Txid = transaction_identifier<false>`.
IIUC, this works because of this conversion function: https://github.com/bitcoin/bitcoin/blob/master/src/util/transaction_identifier.h#L67
A comment suggests for the new code to use `ToUint256` instead: https://github.com/bitcoin/bitcoin/blob/master/src/util/transaction_identifier.h#L62
(https://github.com/bitcoin/bitcoin/pull/31794#discussion_r1954619394)
`RecursiveUpdateTxState()` accepts a `const uint256& tx_hash` as the first argument but `tx.GetHash()` returns a `Txid&`, which is `Txid = transaction_identifier<false>`.
IIUC, this works because of this conversion function: https://github.com/bitcoin/bitcoin/blob/master/src/util/transaction_identifier.h#L67
A comment suggests for the new code to use `ToUint256` instead: https://github.com/bitcoin/bitcoin/blob/master/src/util/transaction_identifier.h#L62
💬 sipa commented on issue "Wallet passpharse":
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656927905)
Please edit your issue then to provide accurate information.
The project's website is bitcoincore.org. The independent website bitcoin.org mirrors binaries for Bitcoin Core, but it's outdated, and doesn't even have 28.0 yet. Which version are you using?
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656927905)
Please edit your issue then to provide accurate information.
The project's website is bitcoincore.org. The independent website bitcoin.org mirrors binaries for Bitcoin Core, but it's outdated, and doesn't even have 28.0 yet. Which version are you using?
💬 InnDe commented on issue "Wallet passpharse":
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656937248)
im using v 27
https://bitcoin.org/en/ this is website i used before and i'm using now
On Thu, 13 Feb 2025 at 18:18, Pieter Wuille ***@***.***>
wrote:
> Please edit your issue then to provide accurate information.
>
> The project's website is bitcoincore.org. The independent website
> bitcoin.org mirrors binaries for Bitcoin Core, but it's outdated, and
> doesn't even have 28.0 yet. Which version are you using?
>
> —
> Reply to this email directly, view it on GitHub
> <https://git
...
(https://github.com/bitcoin/bitcoin/issues/31852#issuecomment-2656937248)
im using v 27
https://bitcoin.org/en/ this is website i used before and i'm using now
On Thu, 13 Feb 2025 at 18:18, Pieter Wuille ***@***.***>
wrote:
> Please edit your issue then to provide accurate information.
>
> The project's website is bitcoincore.org. The independent website
> bitcoin.org mirrors binaries for Bitcoin Core, but it's outdated, and
> doesn't even have 28.0 yet. Which version are you using?
>
> —
> Reply to this email directly, view it on GitHub
> <https://git
...
💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954742963)
The reason I kept it separate is because it's verbose. But happy to move it back.
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954742963)
The reason I kept it separate is because it's verbose. But happy to move it back.
💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954755072)
A miner might naively set it so low that our p2p processing is impacted, potentially getting new blocks later and interfering with transaction relay.
Also, I hope to get rid of this soon(tm) if cluster mempool gives us a more efficient method. It's nice if we don't have to drop a configuration option again.
This is already 60x faster than the long poll behavior of `getblocktemplate`, which nobody complains about. And typical stratum (v1) jobs are refreshed every 30 seconds. https://b10c.me
...
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954755072)
A miner might naively set it so low that our p2p processing is impacted, potentially getting new blocks later and interfering with transaction relay.
Also, I hope to get rid of this soon(tm) if cluster mempool gives us a more efficient method. It's nice if we don't have to drop a configuration option again.
This is already 60x faster than the long poll behavior of `getblocktemplate`, which nobody complains about. And typical stratum (v1) jobs are refreshed every 30 seconds. https://b10c.me
...
💬 achow101 commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1954757379)
It doesn't materially make a difference. Deriving a descriptor from either one will result in the same descriptor, or it's a bug.
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1954757379)
It doesn't materially make a difference. Deriving a descriptor from either one will result in the same descriptor, or it's a bug.
💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954758330)
Additionally there's memory management to worry about, if we really start pushing fresh template at every mempool increment, potentially multiple times per second.
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954758330)
Additionally there's memory management to worry about, if we really start pushing fresh template at every mempool increment, potentially multiple times per second.
💬 ryanofsky commented on issue "doc/zmq: Note about endianness does not match reality":
(https://github.com/bitcoin/bitcoin/issues/31856#issuecomment-2657006696)
Agree with bug report and earlier comment. Relevant ZMQ code is [Lines 220 to 240 in zmqpublishnotifier.cpp](https://github.com/bitcoin/bitcoin/blob/c242fa5be358150d83c2446896b6f4c45c6365e9/src/zmq/zmqpublishnotifier.cpp#L220-L240) and the ZMQ documentation cited is pretty wrong or at least misleading:
> […] 32-byte hashes are in Little Endian and not in the Big Endian format that the RPC interface and block explorers use to display transaction and block hashes. [...]
>
> `| hashtx | <32-byte t
...
(https://github.com/bitcoin/bitcoin/issues/31856#issuecomment-2657006696)
Agree with bug report and earlier comment. Relevant ZMQ code is [Lines 220 to 240 in zmqpublishnotifier.cpp](https://github.com/bitcoin/bitcoin/blob/c242fa5be358150d83c2446896b6f4c45c6365e9/src/zmq/zmqpublishnotifier.cpp#L220-L240) and the ZMQ documentation cited is pretty wrong or at least misleading:
> […] 32-byte hashes are in Little Endian and not in the Big Endian format that the RPC interface and block explorers use to display transaction and block hashes. [...]
>
> `| hashtx | <32-byte t
...
📝 maflcko opened a pull request: " test: Rename send_message to send_without_ping "
(https://github.com/bitcoin/bitcoin/pull/31859)
`send_message` is problematic, because it is easy to forget a `sync_with_ping` (or other `wait_until`), leading to intermittent test failures. (Example: https://github.com/bitcoin/bitcoin/pull/31837#discussion_r1950370246)
There are more uses of `send_and_ping` in the codebase than `send_message`, so in most cases `send_and_ping` is needed anyway.
For the remaining cases, clearly document that no sync happens by renaming `send_message` to `send_without_ping`.
(https://github.com/bitcoin/bitcoin/pull/31859)
`send_message` is problematic, because it is easy to forget a `sync_with_ping` (or other `wait_until`), leading to intermittent test failures. (Example: https://github.com/bitcoin/bitcoin/pull/31837#discussion_r1950370246)
There are more uses of `send_and_ping` in the codebase than `send_message`, so in most cases `send_and_ping` is needed anyway.
For the remaining cases, clearly document that no sync happens by renaming `send_message` to `send_without_ping`.
💬 ryanofsky commented on pull request "Have createNewBlock() wait for tip, make rpc handle shutdown during long poll and wait methods":
(https://github.com/bitcoin/bitcoin/pull/31785#discussion_r1954769058)
> First available number.
Oh, thanks. Didn't notice the numbers were out of order and later ones were used below.
(https://github.com/bitcoin/bitcoin/pull/31785#discussion_r1954769058)
> First available number.
Oh, thanks. Didn't notice the numbers were out of order and later ones were used below.
💬 hodlinator commented on pull request "qa debug: Add --debug_runs/-waitfordebugger [DRAFT]":
(https://github.com/bitcoin/bitcoin/pull/31723#issuecomment-2657022670)
fanquake:
> > Can you configure your IDE to do something like the equivalent of using `gdb`/`lldb`, and `process attach --name bitcoind --waitfor`? So it just grabs bitcoind once it spins up?
>
> I've never seen something like that in an IDE/editor, but I'll have a look, might exist a debugger console which allows that kind of thing.
The only debugging console I get with the IDE states "No Active Debug Session" when I try to input commands. :(
maflcko:
> > This is not about debugg
...
(https://github.com/bitcoin/bitcoin/pull/31723#issuecomment-2657022670)
fanquake:
> > Can you configure your IDE to do something like the equivalent of using `gdb`/`lldb`, and `process attach --name bitcoind --waitfor`? So it just grabs bitcoind once it spins up?
>
> I've never seen something like that in an IDE/editor, but I'll have a look, might exist a debugger console which allows that kind of thing.
The only debugging console I get with the IDE states "No Active Debug Session" when I try to input commands. :(
maflcko:
> > This is not about debugg
...
💬 hebasto commented on pull request "cmake: add a component for each binary":
(https://github.com/bitcoin/bitcoin/pull/31844#issuecomment-2657038440)
Concept ACK.
In addition to installation, components are also intended for use in packaging via [`cpack`](https://cmake.org/cmake/help/latest/manual/cpack.1.html). However, Bitcoin Core does not currently utilise it.
(https://github.com/bitcoin/bitcoin/pull/31844#issuecomment-2657038440)
Concept ACK.
In addition to installation, components are also intended for use in packaging via [`cpack`](https://cmake.org/cmake/help/latest/manual/cpack.1.html). However, Bitcoin Core does not currently utilise it.
💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954786305)
Taken
`Assume(x)` is `x` in production, so in the event of a bug `tip_changed` will be false. So the function will just wait for the deadline and return nothing.
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954786305)
Taken
`Assume(x)` is `x` in production, so in the event of a bug `tip_changed` will be false. So the function will just wait for the deadline and return nothing.
💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954786986)
I incorporated part of this comment. Note that some callers may just not be interested in fee changes, so I mentioned that as well.
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1954786986)
I incorporated part of this comment. Note that some callers may just not be interested in fee changes, so I mentioned that as well.