💬 pinheadmz commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162750500)
Related #29749 signing the cli tools will likely require updates to the macOS signing tools we use for releases
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162750500)
Related #29749 signing the cli tools will likely require updates to the macOS signing tools we use for releases
💬 sipa commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162754801)
@emc99 This issue is about the discussion of packaging of the `bitcoin-cli` client with the macOS release. If you have questions about usage of Bitcoin Core, there are other venues like https://bitcoin.stackexchange.com.
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162754801)
@emc99 This issue is about the discussion of packaging of the `bitcoin-cli` client with the macOS release. If you have questions about usage of Bitcoin Core, there are other venues like https://bitcoin.stackexchange.com.
🤔 sipa reviewed a pull request: "util: add missing VecDeque include"
(https://github.com/bitcoin/bitcoin/pull/30268#pullrequestreview-2112742043)
utACK f51da34ec1a806d321a468691fa66082eef10ad9
(https://github.com/bitcoin/bitcoin/pull/30268#pullrequestreview-2112742043)
utACK f51da34ec1a806d321a468691fa66082eef10ad9
💬 sipa commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#issuecomment-2162765346)
Now actually rebased, after merge of #30160.
(https://github.com/bitcoin/bitcoin/pull/29625#issuecomment-2162765346)
Now actually rebased, after merge of #30160.
💬 fanquake commented on pull request "guix: build with glibc 2.31":
(https://github.com/bitcoin/bitcoin/pull/29987#issuecomment-2162818859)
Guix Build (aarch64):
```bash
aa0ac90d4abc930dee2327985fafdbee9c40c8eeea5738383e798f076db36766 guix-build-b5fc6d46a385/output/aarch64-linux-gnu/SHA256SUMS.part
c25dec340e71ba13b238cc743cb86cb6ee564b05f47a1d3df2240f90b8cdf1cd guix-build-b5fc6d46a385/output/aarch64-linux-gnu/bitcoin-b5fc6d46a385-aarch64-linux-gnu-debug.tar.gz
b7e9627b89d06e2646fcc5430f2eb08ab920039cfa9d4ce14917830bc48ba129 guix-build-b5fc6d46a385/output/aarch64-linux-gnu/bitcoin-b5fc6d46a385-aarch64-linux-gnu.tar.gz
3afe6f
...
(https://github.com/bitcoin/bitcoin/pull/29987#issuecomment-2162818859)
Guix Build (aarch64):
```bash
aa0ac90d4abc930dee2327985fafdbee9c40c8eeea5738383e798f076db36766 guix-build-b5fc6d46a385/output/aarch64-linux-gnu/SHA256SUMS.part
c25dec340e71ba13b238cc743cb86cb6ee564b05f47a1d3df2240f90b8cdf1cd guix-build-b5fc6d46a385/output/aarch64-linux-gnu/bitcoin-b5fc6d46a385-aarch64-linux-gnu-debug.tar.gz
b7e9627b89d06e2646fcc5430f2eb08ab920039cfa9d4ce14917830bc48ba129 guix-build-b5fc6d46a385/output/aarch64-linux-gnu/bitcoin-b5fc6d46a385-aarch64-linux-gnu.tar.gz
3afe6f
...
🚀 glozow merged a pull request: "util: add missing VecDeque include"
(https://github.com/bitcoin/bitcoin/pull/30268)
(https://github.com/bitcoin/bitcoin/pull/30268)
🚀 glozow merged a pull request: "[26.x] backports and final changes for 26.2rc1"
(https://github.com/bitcoin/bitcoin/pull/30260)
(https://github.com/bitcoin/bitcoin/pull/30260)
💬 fanquake commented on pull request "fuzz: Use std::span in FuzzBufferType":
(https://github.com/bitcoin/bitcoin/pull/30229#issuecomment-2162892651)
I think this is ok to do, but you'll need adjust the bitset code instroduced in #30160:
```bash
test/fuzz/bitset.cpp:284:23: error: no matching function for call to 'ReadByte'
unsigned typdat = ReadByte(buffer) % 8;
^~~~~~~~
test/fuzz/bitset.cpp:16:9: note: candidate function not viable: no known conversion from 'FuzzBufferType' (aka 'span<const unsigned char>') to 'Span<const uint8_t> &' (aka 'Span<const unsigned char> &') for 1st argument
uint8_t ReadByte(Span<c
...
(https://github.com/bitcoin/bitcoin/pull/30229#issuecomment-2162892651)
I think this is ok to do, but you'll need adjust the bitset code instroduced in #30160:
```bash
test/fuzz/bitset.cpp:284:23: error: no matching function for call to 'ReadByte'
unsigned typdat = ReadByte(buffer) % 8;
^~~~~~~~
test/fuzz/bitset.cpp:16:9: note: candidate function not viable: no known conversion from 'FuzzBufferType' (aka 'span<const unsigned char>') to 'Span<const uint8_t> &' (aka 'Span<const unsigned char> &') for 1st argument
uint8_t ReadByte(Span<c
...
💬 RichardGantz commented on issue "importaddress failed, Only legacy wallets are supported by this command.":
(https://github.com/bitcoin/bitcoin/issues/29772#issuecomment-2162910393)
I have a bitcoincore v27.0.0 running on a "Raspberry Pi OS with desktop, Release date: March 15th 2024.System: 64-bit,Kernel version: 6.6, Debian version: 12 (bookworm)" over the tor network, which is fully synchronized.
I installed a "Electrum Personal Server v0.2.4, but it does not start because of this same JsonRpcError ("code = -4; message = "Only legacy wallets are supported by this command").
Up to this point I tried several zpubs and addresses, but they were all native segwit P2WPKH.
...
(https://github.com/bitcoin/bitcoin/issues/29772#issuecomment-2162910393)
I have a bitcoincore v27.0.0 running on a "Raspberry Pi OS with desktop, Release date: March 15th 2024.System: 64-bit,Kernel version: 6.6, Debian version: 12 (bookworm)" over the tor network, which is fully synchronized.
I installed a "Electrum Personal Server v0.2.4, but it does not start because of this same JsonRpcError ("code = -4; message = "Only legacy wallets are supported by this command").
Up to this point I tried several zpubs and addresses, but they were all native segwit P2WPKH.
...
💬 marcofleon commented on pull request "fuzz: add I2P harness":
(https://github.com/bitcoin/bitcoin/pull/30230#discussion_r1636394068)
I think it's an acceptable tradeoff, as using mock time makes the test more determinstic. I don't think timeouts are too critical a part of the I2P code, and this harness as is reaches almost all of the code paths in `i2p`.
But I see what you're saying in that advancing time would be a more accurate simulation. Maybe we leave this as a potential follow up on `FuzzedSock`?
(https://github.com/bitcoin/bitcoin/pull/30230#discussion_r1636394068)
I think it's an acceptable tradeoff, as using mock time makes the test more determinstic. I don't think timeouts are too critical a part of the I2P code, and this harness as is reaches almost all of the code paths in `i2p`.
But I see what you're saying in that advancing time would be a more accurate simulation. Maybe we leave this as a potential follow up on `FuzzedSock`?
💬 sipa commented on issue "importaddress failed, Only legacy wallets are supported by this command.":
(https://github.com/bitcoin/bitcoin/issues/29772#issuecomment-2162927360)
The terminology is confusing, but "legacy wallets" and "legacy addresses" have nothing to do with one another:
* legacy wallets are wallet.dat files using the BDB format, and are opposed to sqlite-based wallet files ("descriptor wallets"). Legacy wallet support is being deprecated.
* legacy addresses are P2PKH and P2SH addresses, and are opposed to more modern address types like P2WPKH and P2TR.
What you've done is created a legacy address in a descriptor wallet (which is supported). The is
...
(https://github.com/bitcoin/bitcoin/issues/29772#issuecomment-2162927360)
The terminology is confusing, but "legacy wallets" and "legacy addresses" have nothing to do with one another:
* legacy wallets are wallet.dat files using the BDB format, and are opposed to sqlite-based wallet files ("descriptor wallets"). Legacy wallet support is being deprecated.
* legacy addresses are P2PKH and P2SH addresses, and are opposed to more modern address types like P2WPKH and P2TR.
What you've done is created a legacy address in a descriptor wallet (which is supported). The is
...
💬 emc99 commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162937611)
@sipa I don't see how my questions are off-topic. Why can't we have a free and open discussion of the issues on here? Isn't that what github is for?
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162937611)
@sipa I don't see how my questions are off-topic. Why can't we have a free and open discussion of the issues on here? Isn't that what github is for?
💬 maflcko commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162949886)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162949886)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.
💬 pinheadmz commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162955737)
@emc99 bitcoin development is complicated and busy with hundreds of people focused on different things in harmony. This issue is about macos releases. Your comment is about data usage and therefore does not belong here, in a thread where developers are discussing releases. Sipa has directed you very precisely to the best place to raise your concerns about data usage. If you have any more comments about macOS releases you are in the right place for an organized work as a team.
Further off top
...
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162955737)
@emc99 bitcoin development is complicated and busy with hundreds of people focused on different things in harmony. This issue is about macos releases. Your comment is about data usage and therefore does not belong here, in a thread where developers are discussing releases. Sipa has directed you very precisely to the best place to raise your concerns about data usage. If you have any more comments about macOS releases you are in the right place for an organized work as a team.
Further off top
...
💬 sipa commented on issue "Enable `importprivkey`, `addmultisigaddress` in descriptor wallets":
(https://github.com/bitcoin/bitcoin/issues/30175#issuecomment-2162981138)
@achow101 Hmm, what would happen if `addmultisigaddress` for descriptor wallets just imports the computed descriptor as it does now (with RPC arguments that must be existing addresses or hex pubkeys)? Would it support (participating in) signing for the resulting multisig address (assuming signing for one of specified addresses/pubkeys was possible prior to the RPC call)? Would `listdescriptors true` reveal the corresponding private key?
Agreed about `importmulti`. It's nontrivial to map to de
...
(https://github.com/bitcoin/bitcoin/issues/30175#issuecomment-2162981138)
@achow101 Hmm, what would happen if `addmultisigaddress` for descriptor wallets just imports the computed descriptor as it does now (with RPC arguments that must be existing addresses or hex pubkeys)? Would it support (participating in) signing for the resulting multisig address (assuming signing for one of specified addresses/pubkeys was possible prior to the RPC call)? Would `listdescriptors true` reveal the corresponding private key?
Agreed about `importmulti`. It's nontrivial to map to de
...
💬 m3dwards commented on pull request "ci: move ASan job to GitHub Actions from Cirrus CI":
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636456192)
Done
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636456192)
Done
💬 m3dwards commented on pull request "ci: move ASan job to GitHub Actions from Cirrus CI":
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636456663)
No strong feelings, switched it back to sed approach.
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636456663)
No strong feelings, switched it back to sed approach.
💬 willcl-ark commented on pull request "rename TransactionErrors: MISSING_INPUTS and ALREADY_IN_CHAIN":
(https://github.com/bitcoin/bitcoin/pull/30212#discussion_r1636456867)
I did consider this, but it felt much less exposed to the user, only via `testmempoolaccept` AFAIK:
```cpp
result_inner.pushKV("reject-reason", "missing-inputs");
```
Therefore as an "internal error", `TX_MISSING_INPUTS` (for any reason) it felt more accurate to me to leave as is? Very happy to be persuaded away from this viewpoint though :)
(https://github.com/bitcoin/bitcoin/pull/30212#discussion_r1636456867)
I did consider this, but it felt much less exposed to the user, only via `testmempoolaccept` AFAIK:
```cpp
result_inner.pushKV("reject-reason", "missing-inputs");
```
Therefore as an "internal error", `TX_MISSING_INPUTS` (for any reason) it felt more accurate to me to leave as is? Very happy to be persuaded away from this viewpoint though :)
💬 maflcko commented on issue "Enable `importprivkey`, `addmultisigaddress` in descriptor wallets":
(https://github.com/bitcoin/bitcoin/issues/30175#issuecomment-2163011779)
I think the issue remains that the rescan argument is boolean and optional in `importaddress`, which IIRC was one of the reasons to move toward `importdescriptors`. Yes, the `importdescriptors` interface is non-trivial, but I don't see how the burden can be taken off the user to think about the rescan timestamp of the descriptor. It needs to be accurate, because if it is too late, funds/txs may be missed, if it is too early, hours/days may be spent on a rescan.
If this is done, I'd say that `
...
(https://github.com/bitcoin/bitcoin/issues/30175#issuecomment-2163011779)
I think the issue remains that the rescan argument is boolean and optional in `importaddress`, which IIRC was one of the reasons to move toward `importdescriptors`. Yes, the `importdescriptors` interface is non-trivial, but I don't see how the burden can be taken off the user to think about the rescan timestamp of the descriptor. It needs to be accurate, because if it is too late, funds/txs may be missed, if it is too early, hours/days may be spent on a rescan.
If this is done, I'd say that `
...
💬 maflcko commented on pull request "fuzz: Use std::span in FuzzBufferType":
(https://github.com/bitcoin/bitcoin/pull/30229#issuecomment-2163013314)
Thanks for spotting the silent merge conflict. Rebased.
(https://github.com/bitcoin/bitcoin/pull/30229#issuecomment-2163013314)
Thanks for spotting the silent merge conflict. Rebased.