💬 gmart7t2 commented on issue "importdescriptors always rescans":
(https://github.com/bitcoin/bitcoin/issues/31263#issuecomment-2481760335)
I have that, and it does make it faster. But I still get RPC timeouts when the machine is loaded, particularly if the wallet already has a lot of descriptors in it. It doesn't only rescan for the one(s) I am adding, but also for all the pre-existing descriptors in the wallet.
(https://github.com/bitcoin/bitcoin/issues/31263#issuecomment-2481760335)
I have that, and it does make it faster. But I still get RPC timeouts when the machine is loaded, particularly if the wallet already has a lot of descriptors in it. It doesn't only rescan for the one(s) I am adding, but also for all the pre-existing descriptors in the wallet.
⚠️ achow101 reopened an issue: "importdescriptors always rescans"
(https://github.com/bitcoin/bitcoin/issues/31263)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Running `importdescriptors` with `timestamp: now` rescans the last 2 hours worth of blocks.
The docs say that '"now" can be specified to bypass scanning' but that doesn't appear to be true:
```
"timestamp": timestamp | "now", (integer / string, required) Time from which to start rescanning the blockchain for this descriptor, in UNIX epoch time
...
(https://github.com/bitcoin/bitcoin/issues/31263)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Running `importdescriptors` with `timestamp: now` rescans the last 2 hours worth of blocks.
The docs say that '"now" can be specified to bypass scanning' but that doesn't appear to be true:
```
"timestamp": timestamp | "now", (integer / string, required) Time from which to start rescanning the blockchain for this descriptor, in UNIX epoch time
...
💬 furszy commented on issue "importdescriptors always rescans":
(https://github.com/bitcoin/bitcoin/issues/31263#issuecomment-2481775432)
> I have that, and it does make it faster. But I still get RPC timeouts when the machine is loaded, particularly if the wallet already has a lot of descriptors in it. It doesn't only rescan for the one(s) I am adding, but also for all the pre-existing descriptors in the wallet.
Yes. Thats something I already have in my TO DO list. It requires a rescanning restructuring first.
(https://github.com/bitcoin/bitcoin/issues/31263#issuecomment-2481775432)
> I have that, and it does make it faster. But I still get RPC timeouts when the machine is loaded, particularly if the wallet already has a lot of descriptors in it. It doesn't only rescan for the one(s) I am adding, but also for all the pre-existing descriptors in the wallet.
Yes. Thats something I already have in my TO DO list. It requires a rescanning restructuring first.
💬 PastaPastaPasta commented on pull request "refactor: covert ContainsNoNUL to ContainsNUL":
(https://github.com/bitcoin/bitcoin/pull/31301#discussion_r1845839618)
Applied in https://github.com/bitcoin/bitcoin/pull/31301/commits/6077262788333759f1ddc27539e86cd04ac8d076
(https://github.com/bitcoin/bitcoin/pull/31301#discussion_r1845839618)
Applied in https://github.com/bitcoin/bitcoin/pull/31301/commits/6077262788333759f1ddc27539e86cd04ac8d076
💬 PastaPastaPasta commented on pull request "refactor: covert ContainsNoNUL to ContainsNUL":
(https://github.com/bitcoin/bitcoin/pull/31301#discussion_r1845844350)
I think I disagree here. If the function **had** side effects, it may make sense to not have [[nodiscard]] as you may intend to call the function, without caring what it returns. In this instance though, there is no purpose to call ContainsNUL and not use the returning value, so that would be indicative of a bug.
(https://github.com/bitcoin/bitcoin/pull/31301#discussion_r1845844350)
I think I disagree here. If the function **had** side effects, it may make sense to not have [[nodiscard]] as you may intend to call the function, without caring what it returns. In this instance though, there is no purpose to call ContainsNUL and not use the returning value, so that would be indicative of a bug.
⚠️ Mhsn34866 opened an issue: "سلام من ابتدای ۳۴۸۶۶ را با شوکت فرزند موسی ویدا فرزند علی پگاه فرزند جلال در صنعت دریای حفاری و کشتیرانی ودر زمینه محاسبات حورا فرزند علی پرویز اسم باباشو یادم نیست و دبیر ریاضیم اقای امروانی که فامیلیشو عوض کرد و خرید یک جایگاه دیگه ۳۴۸۶۶ از پول اولین بالانس ۶ تا تقصیم سلولی برای خودم هستم . "
(https://github.com/bitcoin/bitcoin/issues/31309)
(https://github.com/bitcoin/bitcoin/issues/31309)
💬 Mhsn34866 commented on issue "سلام من ابتدای ۳۴۸۶۶ را با شوکت فرزند موسی ویدا فرزند علی پگاه فرزند جلال در صنعت دریای حفاری و کشتیرانی ودر زمینه محاسبات حورا فرزند علی پرویز اسم باباشو یادم نیست و دبیر ریاضیم اقای امروانی که فامیلیشو عوض کرد و خرید یک جایگاه دیگه ۳۴۸۶۶ از پول اولین بالانس ۶ تا تقصیم سلولی برای خودم هستم . ":
(https://github.com/bitcoin/bitcoin/issues/31309#issuecomment-2481903736)
پیگیری و تجزیه و تحلیل پایه ثابط د. محاسبات برای رو نمای از بوجیه پنهان تامین کنندیه بازار طبق احراز هویت صحیح و نجات اقتصاد کریه زمین دلیل مراجعه من به سیستم میباشد
(https://github.com/bitcoin/bitcoin/issues/31309#issuecomment-2481903736)
پیگیری و تجزیه و تحلیل پایه ثابط د. محاسبات برای رو نمای از بوجیه پنهان تامین کنندیه بازار طبق احراز هویت صحیح و نجات اقتصاد کریه زمین دلیل مراجعه من به سیستم میباشد
⚠️ Mhsn34866 opened an issue: "پیگیری و حراست و محافظت هوش مصنوعی در قبال جوهر هوشمند دیجیتال یا ولم و کلید بازار "
(https://github.com/bitcoin/bitcoin/issues/31310)
(https://github.com/bitcoin/bitcoin/issues/31310)
✅ achow101 closed an issue: "سلام من ابتدای ۳۴۸۶۶ را با شوکت فرزند موسی ویدا فرزند علی پگاه فرزند جلال در صنعت دریای حفاری و کشتیرانی ودر زمینه محاسبات حورا فرزند علی پرویز اسم باباشو یادم نیست و دبیر ریاضیم اقای امروانی که فامیلیشو عوض کرد و خرید یک جایگاه دیگه ۳۴۸۶۶ از پول اولین بالانس ۶ تا تقصیم سلولی برای خودم هستم . "
(https://github.com/bitcoin/bitcoin/issues/31309)
(https://github.com/bitcoin/bitcoin/issues/31309)
:lock: achow101 locked an issue: "سلام من ابتدای ۳۴۸۶۶ را با شوکت فرزند موسی ویدا فرزند علی پگاه فرزند جلال در صنعت دریای حفاری و کشتیرانی ودر زمینه محاسبات حورا فرزند علی پرویز اسم باباشو یادم نیست و دبیر ریاضیم اقای امروانی که فامیلیشو عوض کرد و خرید یک جایگاه دیگه ۳۴۸۶۶ از پول اولین بالانس ۶ تا تقصیم سلولی برای خودم هستم . "
(https://github.com/bitcoin/bitcoin/issues/31309)
(https://github.com/bitcoin/bitcoin/issues/31309)
✅ achow101 closed an issue: "."
(https://github.com/bitcoin/bitcoin/issues/31310)
(https://github.com/bitcoin/bitcoin/issues/31310)
:lock: achow101 locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/31310)
(https://github.com/bitcoin/bitcoin/issues/31310)
💬 pythcoiner commented on pull request "wallet: BIP 326 sequence based anti-fee-snipe for taproot inputs":
(https://github.com/bitcoin/bitcoin/pull/24128#issuecomment-2481930460)
tACK faf4c7107bafc8b0db48909f37e4a242107b804a modulo rebase
reviewed & write [this tests](https://github.com/pythcoiner/bitcoin_tests/blob/24128/src/main.rs) that verify:
- when all inputs are taproot anti fee sniping is 50/50 nSequence/nLockTime
- when nSequence, the input index is randomly chosen
- when nLocktime, 10% are 1-100 blocks behind the current height
- when there is some non-taproot inputs, anti fee sniping is always nLocktime
- when there is some non-confirmed in
...
(https://github.com/bitcoin/bitcoin/pull/24128#issuecomment-2481930460)
tACK faf4c7107bafc8b0db48909f37e4a242107b804a modulo rebase
reviewed & write [this tests](https://github.com/pythcoiner/bitcoin_tests/blob/24128/src/main.rs) that verify:
- when all inputs are taproot anti fee sniping is 50/50 nSequence/nLockTime
- when nSequence, the input index is randomly chosen
- when nLocktime, 10% are 1-100 blocks behind the current height
- when there is some non-taproot inputs, anti fee sniping is always nLocktime
- when there is some non-confirmed in
...
💬 maflcko commented on pull request "refactor: convert ContainsNoNUL to ContainsNUL":
(https://github.com/bitcoin/bitcoin/pull/31301#discussion_r1846027455)
I guess once there is C++23, we could just remove this function and use `str.contains('\0')` directly everywhere instead of `ContainsNUL(str)`? If so, a simple comment to say so may be sufficient to avoid having to touch the same lines twice?
(https://github.com/bitcoin/bitcoin/pull/31301#discussion_r1846027455)
I guess once there is C++23, we could just remove this function and use `str.contains('\0')` directly everywhere instead of `ContainsNUL(str)`? If so, a simple comment to say so may be sufficient to avoid having to touch the same lines twice?
💬 naumenkogs commented on pull request "Package validation: accept packages of size 1":
(https://github.com/bitcoin/bitcoin/pull/31096#discussion_r1846051102)
Weird UI indeed, i left a reply and I'll try to monitor that thread now.
(https://github.com/bitcoin/bitcoin/pull/31096#discussion_r1846051102)
Weird UI indeed, i left a reply and I'll try to monitor that thread now.
💬 maflcko commented on pull request "build: Temporarily disable compiling `fuzz/utxo_snapshot.cpp` with MSVC":
(https://github.com/bitcoin/bitcoin/pull/31307#issuecomment-2482232825)
lgtm ACK b2d536100282bd901d3e0be7f7f4a6966e0ef817
(https://github.com/bitcoin/bitcoin/pull/31307#issuecomment-2482232825)
lgtm ACK b2d536100282bd901d3e0be7f7f4a6966e0ef817
💬 maflcko commented on issue "MSVC 17.12.0 internal compiler error ":
(https://github.com/bitcoin/bitcoin/issues/31303#issuecomment-2482236115)
According to https://github.com/bitcoin/bitcoin/pull/27930#issuecomment-1602985185 MSVC is including Bitcoin Core in an internal test-suite, but I guess they are not compiling the fuzz tests? cc @CaseyCarter
(https://github.com/bitcoin/bitcoin/issues/31303#issuecomment-2482236115)
According to https://github.com/bitcoin/bitcoin/pull/27930#issuecomment-1602985185 MSVC is including Bitcoin Core in an internal test-suite, but I guess they are not compiling the fuzz tests? cc @CaseyCarter
💬 naumenkogs commented on pull request "policy: ephemeral dust followups":
(https://github.com/bitcoin/bitcoin/pull/31279#issuecomment-2482237418)
ACK 5679f398e2a3ab8315d39ee674ccb8ad6a8f73c7
(https://github.com/bitcoin/bitcoin/pull/31279#issuecomment-2482237418)
ACK 5679f398e2a3ab8315d39ee674ccb8ad6a8f73c7
💬 naumenkogs commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#issuecomment-2482268618)
ACK https://github.com/bitcoin/bitcoin/commit/5736d1ddacc4019101e7a5170dd25efbc63b622a
My concern above was related to LimitMempoolSize(), but indeed it's easy to see it doesn't happen between the two `m_changeset->Apply()` calls .
(https://github.com/bitcoin/bitcoin/pull/31122#issuecomment-2482268618)
ACK https://github.com/bitcoin/bitcoin/commit/5736d1ddacc4019101e7a5170dd25efbc63b622a
My concern above was related to LimitMempoolSize(), but indeed it's easy to see it doesn't happen between the two `m_changeset->Apply()` calls .
💬 maflcko commented on pull request "refactor: Fix remaining clang-tidy performance-inefficient-vector errors":
(https://github.com/bitcoin/bitcoin/pull/31305#issuecomment-2482277836)
lgtm ACK 9cb24f82cf88607e289bd53833a9bb0976653b26
(https://github.com/bitcoin/bitcoin/pull/31305#issuecomment-2482277836)
lgtm ACK 9cb24f82cf88607e289bd53833a9bb0976653b26