⚠️ benma opened an issue: "docs: Wrong/outdated docs for `tr(KEY)` in doc/descriptors.md"
(https://github.com/bitcoin/bitcoin/issues/30279)
Bitcoin Core uses BIP-386 for `tr(...)` descriptors, and in the case of `tr(KEY)`, the produced key is tweaked according to BIP-341:

https://github.com/bitcoin/bips/blob/85cda4e225b4d5fd7aff403f69d827f23f6afbbc/bip-0341.mediawiki?plain=1#L156

In the current descriptors.md, it is documented that `tr(KEY)` uses `KEY` as the internal key, with no further comment:

https://github.com/bitcoin/bitcoin/blob/a7bc9b76e73f04dfe4d6ba42033fe38659090e8b/doc/descriptors.md?plain=1#L82

By looking o
...

💬 achow101 commented on pull request "kernel: Streamline util library":
(https://github.com/bitcoin/bitcoin/pull/29015#issuecomment-2163880342)
ACK c7376babd19d0c858fef93ebd58338abd530c1f4

🚀 achow101 merged a pull request: "kernel: Streamline util library"
(https://github.com/bitcoin/bitcoin/pull/29015)

💬 sipa commented on pull request "Low-level cluster linearization code":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1637102449)
Done. I've encapsulated the `std::pair<SetType, FeeFrac>` for representing sets with their feerates into a new `SetInfo<SetType>` type, and changed the return type of candidate finders which count iterations to be `std::pair<SetInfo<SetType>, uint64_t>`, representing the found candidate and the number of performed iterations. I've also changed the Linearization functions to just return a `bool optimal`, rather than an iteration count (as it wasn't used anywhere anyway).

💬 sipa commented on pull request "Low-level cluster linearization code":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1637102621)
Done.

💬 sipa commented on pull request "Low-level cluster linearization code":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1637102708)
Done.

💬 sipa commented on pull request "Low-level cluster linearization code":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1637103088)
Indeed. I've added a comment. LMK whether it's clearer now.

💬 achow101 commented on pull request "Lint: Support running individual lint checks":
(https://github.com/bitcoin/bitcoin/pull/30219#issuecomment-2163920227)
ACK 0fcbfdb7ad172e518a10dd6e5be4cb6bb1158784

🚀 achow101 merged a pull request: "Lint: Support running individual lint checks"
(https://github.com/bitcoin/bitcoin/pull/30219)

💬 achow101 commented on pull request "Migrate legacy wallets that are not loaded":
(https://github.com/bitcoin-core/gui/pull/824#issuecomment-2163926995)
> > To deal with this, I've opted to just add a button to the migration dialog box that has the user enter their passphrase first, along with instructional text to use that button if their wallet was encrypted.
>
> If we're preemptively making UX changes just to avoid changing UX in the future, it seems like we shouldn't take shortcuts like this... :/

We already do this in the RPC too, for exactly the same reason.

💬 achow101 commented on issue "docs: Wrong/outdated docs for `tr(KEY)` in doc/descriptors.md":
(https://github.com/bitcoin/bitcoin/issues/30279#issuecomment-2163930686)
I thought the phrase "internal key" is unambiguous to mean that the key will need tweaking, as that is how BIP 341 defines that phrase.

It might make sense to remove descriptors.md since it's ostensibly superseded by the BIPs too.

💬 AngusP commented on pull request "test: Add Compact Block Encoding test `ReceiveWithExtraTransactions` covering non-empty `extra_txn`":
(https://github.com/bitcoin/bitcoin/pull/30237#issuecomment-2163943260)
Pushed 09b90c6 which makes the tests deterministic by using predictable 'random' numbers.

Using this to reproduce the issue @dergoegge pointed out:

```patch
diff --git a/src/blockencodings.cpp b/src/blockencodings.cpp
index 695e8d806a..64d635a97a 100644
--- a/src/blockencodings.cpp
+++ b/src/blockencodings.cpp
@@ -44,7 +44,8 @@ void CBlockHeaderAndShortTxIDs::FillShortTxIDSelector() const {

uint64_t CBlockHeaderAndShortTxIDs::GetShortID(const Wtxid& wtxid) const {
static_ass
...

💬 AngusP commented on pull request "test: switch from curl to urllib for HTTP requests":
(https://github.com/bitcoin/bitcoin/pull/29970#discussion_r1637144977)
You can `response.read(amt=<number of bytes>)` so it could be chunked to avoid loading the whole thing in to memory. That *could* also be used to add back some coarse progress indicator

💬 AngusP commented on pull request "test: switch from curl to urllib for HTTP requests":
(https://github.com/bitcoin/bitcoin/pull/29970#discussion_r1637147093)
With curl that makes sense, though here the `urlopen` will raise a `HTTPError` on a 404 for both a `GET` and `HEAD` request, so the earlier HEAD does seem superfluous?

⚠️ 6037701556160635 opened an issue: "yoones65857@gmail.com"
(https://github.com/bitcoin/bitcoin/issues/30280)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

yoones65857@gmail.com

### Expected behaviour

سید یونس سرابی

### Steps to reproduce

6219861961488110

### Relevant log output

سید یونس سرابی

### How did you obtain Bitcoin Core

Compiled from source

### What version of Bitcoin Core are you using?

EQApj7FThO0mCP703BxOkb272FvDGQJIV9IlQZieKVW-_bKf

### Operating system and version

6219861961488110

### Machine specifications

Yoones
...

💬 6037701556160635 commented on issue "yoones65857@gmail.com":
(https://github.com/bitcoin/bitcoin/issues/30280#issuecomment-2163972406)
سید یونس سرابی

💬 6037701556160635 commented on issue "yoones65857@gmail.com":
(https://github.com/bitcoin/bitcoin/issues/30280#issuecomment-2163972703)
Yoones

✅ willcl-ark closed an issue: "yoones65857@gmail.com"
(https://github.com/bitcoin/bitcoin/issues/30280)

💬 6037701556160635 commented on issue "yoones65857@gmail.com":
(https://github.com/bitcoin/bitcoin/issues/30280#issuecomment-2163973745)
yoones65857@gmail.com

💬 Hokulans commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2163995130)
Going to the police
Sent from my iPhone

On Jun 11, 2024, at 10:37 PM, Eoin McQuinn ***@***.***> wrote:



But bitcoin core won't function without a copy of the blockchain, which is 550GiB in size

—
Reply to this email directly, view it on GitHub<https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162431253>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BJALMKMP5UFWC5C47PW4OX3ZHACEXAVCNFSM6AAAAABJCRFPR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSGQZTCM
...