π hebasto approved a pull request: "refactor: remove in-code warning suppression"
(https://github.com/bitcoin/bitcoin/pull/28002#pullrequestreview-1505907503)
ACK 3210f224dbeaf0f9de09d4e83c3e6666128a6717
(https://github.com/bitcoin/bitcoin/pull/28002#pullrequestreview-1505907503)
ACK 3210f224dbeaf0f9de09d4e83c3e6666128a6717
π¬ MarcoFalke commented on pull request "Exit and show error if unrecognized command line args are present":
(https://github.com/bitcoin-core/gui/pull/742#issuecomment-1613669507)
I always wondered why the code wasn't the same. Was this needed for payment requests, when they were linked to be opened by the gui application?
(https://github.com/bitcoin-core/gui/pull/742#issuecomment-1613669507)
I always wondered why the code wasn't the same. Was this needed for payment requests, when they were linked to be opened by the gui application?
π¬ hebasto commented on pull request "contrib: add macOS test for fixup_chains usage":
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613675709)
Concept ACK.
> Another reasonable option would be to bump ld64, but since this is the last thing we should ever need from it, I agree patching makes more sense.
So, what is the plan for bumping ld64 in the future?
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613675709)
Concept ACK.
> Another reasonable option would be to bump ld64, but since this is the last thing we should ever need from it, I agree patching makes more sense.
So, what is the plan for bumping ld64 in the future?
π¬ fanquake commented on pull request "contrib: add macOS test for fixup_chains usage":
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613679524)
> So, what is the plan for bumping ld64 in the future?
Use LLD.
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613679524)
> So, what is the plan for bumping ld64 in the future?
Use LLD.
π¬ hebasto commented on pull request "contrib: add macOS test for fixup_chains usage":
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613687508)
> > So, what is the plan for bumping ld64 in the future?
>
> Use LLD.
Ah, I can see that the first commit has been pulled from https://github.com/bitcoin/bitcoin/pull/21778.
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613687508)
> > So, what is the plan for bumping ld64 in the future?
>
> Use LLD.
Ah, I can see that the first commit has been pulled from https://github.com/bitcoin/bitcoin/pull/21778.
π¬ jonatack commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1247025846)
Up to C++11, my understanding was to avoid `auto` with uniform (braced) initialization because in some cases it could have unexpected results. Since C++17, that was mostly fixed and the CPP Guideline is to [prefer the {}-initializer syntax](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es23-prefer-the--initializer-syntax) as its rules are simpler, more general, less ambiguous, and safer. See also https://ianyepan.github.io/posts/cpp-uniform-initialization/. Though it didn't matte
...
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1247025846)
Up to C++11, my understanding was to avoid `auto` with uniform (braced) initialization because in some cases it could have unexpected results. Since C++17, that was mostly fixed and the CPP Guideline is to [prefer the {}-initializer syntax](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es23-prefer-the--initializer-syntax) as its rules are simpler, more general, less ambiguous, and safer. See also https://ianyepan.github.io/posts/cpp-uniform-initialization/. Though it didn't matte
...
β οΈ Skylerspencer opened an issue: "Stole wallet and paperwork fraude and robbery this ea stolen from my assets with the help of others dates change false tells created I have the original with dates and time you guys did get all of them showing the truth also the Ethereum accounts stole change dates dates I have yoke pocket all the way to now and father dates times contracts you guys are in deeper you gotta keep lieng stilling my assets with the help of Debbie she told you I knew she would tell you about my Bitcoin and you would come I needemore evidence to prove ,y cases thanks. "
(https://github.com/bitcoin-core/gui/issues/743)
(https://github.com/bitcoin-core/gui/issues/743)
π¬ sipa commented on pull request "Miniscript: always treat unsatisfiable scripts as insane":
(https://github.com/bitcoin/bitcoin/pull/27997#issuecomment-1613689759)
So I think the definition for "sane" that we want is "does the apparent policy of this miniscript match its actual semantics" - if you drop all wrappers and naively replace all fragments with their corresponding policy, is that guaranteed to match the policy of the actual script.
Arguably, this is the case for "0", despite not having any keys, because its apparent policy is that it's never spendable, and that is also what it actually implements. Of course, we could expand the definition and e
...
(https://github.com/bitcoin/bitcoin/pull/27997#issuecomment-1613689759)
So I think the definition for "sane" that we want is "does the apparent policy of this miniscript match its actual semantics" - if you drop all wrappers and naively replace all fragments with their corresponding policy, is that guaranteed to match the policy of the actual script.
Arguably, this is the case for "0", despite not having any keys, because its apparent policy is that it's never spendable, and that is also what it actually implements. Of course, we could expand the definition and e
...
β
fanquake closed an issue: "Stole wallet and paperwork fraude and robbery this ea stolen from my assets with the help of others dates change false tells created I have the original with dates and time you guys did get all of them showing the truth also the Ethereum accounts stole change dates dates I have yoke pocket all the way to now and father dates times contracts you guys are in deeper you gotta keep lieng stilling my assets with the help of Debbie she told you I knew she would tell you about my Bitcoin and you would come I needemore evidence to prove ,y cases thanks. "
(https://github.com/bitcoin-core/gui/issues/743)
(https://github.com/bitcoin-core/gui/issues/743)
:lock: fanquake locked an issue: "Stole wallet and paperwork fraude and robbery this ea stolen from my assets with the help of others dates change false tells created I have the original with dates and time you guys did get all of them showing the truth also the Ethereum accounts stole change dates dates I have yoke pocket all the way to now and father dates times contracts you guys are in deeper you gotta keep lieng stilling my assets with the help of Debbie she told you I knew she would tell you about my Bitcoin and you would come I needemore evidence to prove ,y cases thanks. "
(https://github.com/bitcoin-core/gui/issues/743)
(https://github.com/bitcoin-core/gui/issues/743)
π¬ sipa commented on pull request "util: Allow std::byte and char Span serialization":
(https://github.com/bitcoin/bitcoin/pull/27927#issuecomment-1613702864)
> I think that should be fine to add, once there is a use case. Or is there already one?
Not that I know, no. I was more wondering why we'd only add a specialized one for byte-like types when a generic one for all spans would work equally well. And I think the answer is that even with a generic one, we'd probably want a more efficient specialization for byte-like types anyway, to avoid processing one byte at a time.
(https://github.com/bitcoin/bitcoin/pull/27927#issuecomment-1613702864)
> I think that should be fine to add, once there is a use case. Or is there already one?
Not that I know, no. I was more wondering why we'd only add a specialized one for byte-like types when a generic one for all spans would work equally well. And I think the answer is that even with a generic one, we'd probably want a more efficient specialization for byte-like types anyway, to avoid processing one byte at a time.
π¬ MarcoFalke commented on issue "Intermittent failures in interface_usdt_mempool.py":
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1613723053)
https://cirrus-ci.com/task/4626519738286080?logs=ci#L3262
```
node0 2023-06-29T19:45:37.525879Z (mocktime: 2023-07-13T19:45:38Z) [httpworker.2] [rpc/request.cpp:181] [parse] [rpc] ThreadRPCServer method=getrawmempool user=__cookie__
test 2023-06-29T19:45:37.526000Z TestFramework (INFO): Polling buffer...
test 2023-06-29T19:45:37.527000Z TestFramework (INFO): Ensuring mempool:rejected event was handled successfully...
test 2023-06-29T19:45:37.527000Z TestFramework (ERROR): Assert
...
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1613723053)
https://cirrus-ci.com/task/4626519738286080?logs=ci#L3262
```
node0 2023-06-29T19:45:37.525879Z (mocktime: 2023-07-13T19:45:38Z) [httpworker.2] [rpc/request.cpp:181] [parse] [rpc] ThreadRPCServer method=getrawmempool user=__cookie__
test 2023-06-29T19:45:37.526000Z TestFramework (INFO): Polling buffer...
test 2023-06-29T19:45:37.527000Z TestFramework (INFO): Ensuring mempool:rejected event was handled successfully...
test 2023-06-29T19:45:37.527000Z TestFramework (ERROR): Assert
...
π¬ MarcoFalke commented on issue "Error: no RPC connection" when trying to run Bitcoin Core functional tests":
(https://github.com/bitcoin/bitcoin/issues/28000#issuecomment-1613727692)
Let us know if this is still an issue
(https://github.com/bitcoin/bitcoin/issues/28000#issuecomment-1613727692)
Let us know if this is still an issue
β
MarcoFalke closed an issue: "Error: no RPC connection" when trying to run Bitcoin Core functional tests"
(https://github.com/bitcoin/bitcoin/issues/28000)
(https://github.com/bitcoin/bitcoin/issues/28000)
π¬ MarcoFalke commented on pull request "util: Allow std::byte and char Span serialization":
(https://github.com/bitcoin/bitcoin/pull/27927#issuecomment-1613732499)
Yeah, I am planning to do a more thorough cleanup with C++20, see my comment directly above and the other one earlier in the thread:
> Also, `Span<B>` could be used internally to serialize byte-holding (pre)vectors. In fact this is likely a performance bug-fix, because currently, serialization accepts `std::vector<B>` for `B=signed char`, or `B=int8_t`. (`B=char` is deleted). However, serialization seems to only apply the optimization to only call `write` once for `B=unsigned char`. See
>
...
(https://github.com/bitcoin/bitcoin/pull/27927#issuecomment-1613732499)
Yeah, I am planning to do a more thorough cleanup with C++20, see my comment directly above and the other one earlier in the thread:
> Also, `Span<B>` could be used internally to serialize byte-holding (pre)vectors. In fact this is likely a performance bug-fix, because currently, serialization accepts `std::vector<B>` for `B=signed char`, or `B=int8_t`. (`B=char` is deleted). However, serialization seems to only apply the optimization to only call `write` once for `B=unsigned char`. See
>
...
π techy2 opened a pull request: "fix: delay in TimeOffset applied to AdjustedTime caused by send/receiβ¦"
(https://github.com/bitcoin/bitcoin/pull/28007)
On busy VPS and shared host with limited resources, the time between when a messages is sent to the tcpip send or receive
queue and when it is sent in the case of send queue, or when it is processed (ProcessMessage) can be in excess of 30 seconds.
This delay introduces a skew in AdjustedTime.
For the receive queue, the post processing uses the receive time prior to entering the queue to calculate TimeOffset rather than Now() which currently includes the delay in the queue.
For the sen
...
(https://github.com/bitcoin/bitcoin/pull/28007)
On busy VPS and shared host with limited resources, the time between when a messages is sent to the tcpip send or receive
queue and when it is sent in the case of send queue, or when it is processed (ProcessMessage) can be in excess of 30 seconds.
This delay introduces a skew in AdjustedTime.
For the receive queue, the post processing uses the receive time prior to entering the queue to calculate TimeOffset rather than Now() which currently includes the delay in the queue.
For the sen
...
π¬ MarcoFalke commented on pull request "fix: delay in TimeOffset applied to AdjustedTime caused by send/receiβ¦":
(https://github.com/bitcoin/bitcoin/pull/28007#issuecomment-1613756862)
Duplicate of https://github.com/bitcoin/bitcoin/pull/6642?
(https://github.com/bitcoin/bitcoin/pull/28007#issuecomment-1613756862)
Duplicate of https://github.com/bitcoin/bitcoin/pull/6642?
π¬ MarcoFalke commented on pull request "fix: delay in TimeOffset applied to AdjustedTime caused by send/receiβ¦":
(https://github.com/bitcoin/bitcoin/pull/28007#issuecomment-1613758123)
See also #25908
(https://github.com/bitcoin/bitcoin/pull/28007#issuecomment-1613758123)
See also #25908
π¬ MarcoFalke commented on pull request "wallet: Implement independent BDB parser":
(https://github.com/bitcoin/bitcoin/pull/26606#discussion_r1247132355)
```suggestion
throw std::ios_base::failure("AutoFile::seek: file handle is nullptr");
```
?
(https://github.com/bitcoin/bitcoin/pull/26606#discussion_r1247132355)
```suggestion
throw std::ios_base::failure("AutoFile::seek: file handle is nullptr");
```
?
π¬ john-moffett commented on pull request "Exit and show error if unrecognized command line args are present":
(https://github.com/bitcoin-core/gui/pull/742#issuecomment-1613768548)
I'm not entirely sure why they weren't the same. In the beginning, `bitcoind` would handle RPC commands. Then QT got special-cased so that you [couldn't do that](https://github.com/theuni/bitcoin/commit/b2d1129f27a499fa00ab8f5b8f0e9f926ae66362) for `bitcoin-qt` -- though it wouldn't give any errors. It would just silently ignore the subsequent options.
Then the argument-handling code split entirely [here](https://github.com/bitcoin/bitcoin/pull/690). Now `bitcoind` and `bitcoin-qt` mostly did
...
(https://github.com/bitcoin-core/gui/pull/742#issuecomment-1613768548)
I'm not entirely sure why they weren't the same. In the beginning, `bitcoind` would handle RPC commands. Then QT got special-cased so that you [couldn't do that](https://github.com/theuni/bitcoin/commit/b2d1129f27a499fa00ab8f5b8f0e9f926ae66362) for `bitcoin-qt` -- though it wouldn't give any errors. It would just silently ignore the subsequent options.
Then the argument-handling code split entirely [here](https://github.com/bitcoin/bitcoin/pull/690). Now `bitcoind` and `bitcoin-qt` mostly did
...