💬 sr-gi commented on pull request "test: Makes `wait_for_getdata` delete data on checks, plus allows to check the getdata message type":
(https://github.com/bitcoin/bitcoin/pull/29748#issuecomment-2047613487)
> Regarding this comment, I tried this refactor and the tests pass.
Thanks! I think I may have been locking the `p2p_lock` twice which made test timeout.
(https://github.com/bitcoin/bitcoin/pull/29748#issuecomment-2047613487)
> Regarding this comment, I tried this refactor and the tests pass.
Thanks! I think I may have been locking the `p2p_lock` twice which made test timeout.
💬 sr-gi commented on pull request "test: Extends wait_for_getheaders so a specific block hash can be checked":
(https://github.com/bitcoin/bitcoin/pull/29736#issuecomment-2047665322)
I wonder if it may be worth splitting the `wait_for_getheaders` function so the internal function can also be used externally, so we can use that to check for whether a certain message exists without waiting for them (e.g. checking for the negative case) in a similar fashion as done in bc844fd8a7d130bfb7cf598f5b1acd87acd70e58
This way we would get rid of a bunch of manual checks like:
```python
with p2p_lock:
assert "getheaders" not in peer.last_message
```
cc/ @maflcko @stratosp
...
(https://github.com/bitcoin/bitcoin/pull/29736#issuecomment-2047665322)
I wonder if it may be worth splitting the `wait_for_getheaders` function so the internal function can also be used externally, so we can use that to check for whether a certain message exists without waiting for them (e.g. checking for the negative case) in a similar fashion as done in bc844fd8a7d130bfb7cf598f5b1acd87acd70e58
This way we would get rid of a bunch of manual checks like:
```python
with p2p_lock:
assert "getheaders" not in peer.last_message
```
cc/ @maflcko @stratosp
...
👍 BrandonOdiwuor approved a pull request: "test: Extends wait_for_getheaders so a specific block hash can be checked"
(https://github.com/bitcoin/bitcoin/pull/29736#pullrequestreview-1991823634)
crACK c4f857cc301d856f3c60acbe6271d3fe19441c7a
(https://github.com/bitcoin/bitcoin/pull/29736#pullrequestreview-1991823634)
crACK c4f857cc301d856f3c60acbe6271d3fe19441c7a
💬 murchandamus commented on pull request "[DO NOT MERGE] testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2047673316)
Since some people consider the blockstorms an interesting feature of Testnet3, it might be interesting to only raise the difficulty of the delayed block exception to 100,000 instead of 1,000,000. This would allow the network to return to the organic difficulty in fewer difficulty periods and slow down the blockstorms but not remove the feature altogether. My understanding is that this would correspond roughly a tenth of one S9 mining on the network, so if no one had mined for a while, a single S
...
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2047673316)
Since some people consider the blockstorms an interesting feature of Testnet3, it might be interesting to only raise the difficulty of the delayed block exception to 100,000 instead of 1,000,000. This would allow the network to return to the organic difficulty in fewer difficulty periods and slow down the blockstorms but not remove the feature altogether. My understanding is that this would correspond roughly a tenth of one S9 mining on the network, so if no one had mined for a while, a single S
...
💬 maflcko commented on pull request "rpc: validate fee estimation mode case insensitive":
(https://github.com/bitcoin/bitcoin/pull/29175#issuecomment-2047676950)
This is probably more than you wanted to do, but I'd say it would be better to use `FeeModeFromString` to re-use the existing (case-insensitive) parsing code, than to re-implement the parsing and use hard-coded "unset" strings in all call places.
(https://github.com/bitcoin/bitcoin/pull/29175#issuecomment-2047676950)
This is probably more than you wanted to do, but I'd say it would be better to use `FeeModeFromString` to re-use the existing (case-insensitive) parsing code, than to re-implement the parsing and use hard-coded "unset" strings in all call places.
💬 rkrux commented on pull request "test: Makes `wait_for_getdata` delete data on checks, plus allows to check the getdata message type":
(https://github.com/bitcoin/bitcoin/pull/29748#discussion_r1559533843)
Note: This will pop from last message via `check_last_getdata()` call as well, which is different from previous commits. That's why I accepted `last_data` as an argument in my suggestion.
Is popping in `check_last_getdata` also fine?
(https://github.com/bitcoin/bitcoin/pull/29748#discussion_r1559533843)
Note: This will pop from last message via `check_last_getdata()` call as well, which is different from previous commits. That's why I accepted `last_data` as an argument in my suggestion.
Is popping in `check_last_getdata` also fine?
💬 sr-gi commented on pull request "test: Makes `wait_for_getdata` delete data on checks, plus allows to check the getdata message type":
(https://github.com/bitcoin/bitcoin/pull/29748#discussion_r1559541059)
Yeah, I noticed that on your suggestion, but I don't think we do reuse the value in any test (same as with `wait_for_*`)
(https://github.com/bitcoin/bitcoin/pull/29748#discussion_r1559541059)
Yeah, I noticed that on your suggestion, but I don't think we do reuse the value in any test (same as with `wait_for_*`)
💬 willcl-ark commented on issue ""Rolling forward" at startup can take a long time, and is not interruptible":
(https://github.com/bitcoin/bitcoin/issues/11600#issuecomment-2047703916)
The next step here is to make it interruptable.
(https://github.com/bitcoin/bitcoin/issues/11600#issuecomment-2047703916)
The next step here is to make it interruptable.
✅ willcl-ark closed an issue: "bitcoin core crashes when too many rpc calls are made"
(https://github.com/bitcoin/bitcoin/issues/11368)
(https://github.com/bitcoin/bitcoin/issues/11368)
💬 willcl-ark commented on issue "bitcoin core crashes when too many rpc calls are made":
(https://github.com/bitcoin/bitcoin/issues/11368#issuecomment-2047705793)
The problem is not easily reproducible.
Please open a new issue (or leave a comment in here if you want this re-opened) if you experience the problem again.
(https://github.com/bitcoin/bitcoin/issues/11368#issuecomment-2047705793)
The problem is not easily reproducible.
Please open a new issue (or leave a comment in here if you want this re-opened) if you experience the problem again.
💬 fanquake commented on pull request "guix: replace GCC unaligned VMOV patch with binutils patch":
(https://github.com/bitcoin/bitcoin/pull/29846#issuecomment-2047707127)
> Will this close https://github.com/bitcoin/bitcoin/issues/28413 ?
Not quite, we don't yet have a check. I'd still like to add one, but given we've still got occurances, we'd currently have to add exceptions in some way.
(https://github.com/bitcoin/bitcoin/pull/29846#issuecomment-2047707127)
> Will this close https://github.com/bitcoin/bitcoin/issues/28413 ?
Not quite, we don't yet have a check. I'd still like to add one, but given we've still got occurances, we'd currently have to add exceptions in some way.
💬 willcl-ark commented on issue "bumpfee behavior with "Subtract fee from amount"":
(https://github.com/bitcoin/bitcoin/issues/11122#issuecomment-2047714288)
@achow101 is this fixed by https://github.com/bitcoin/bitcoin/issues/22007 ?
(https://github.com/bitcoin/bitcoin/issues/11122#issuecomment-2047714288)
@achow101 is this fixed by https://github.com/bitcoin/bitcoin/issues/22007 ?
✅ willcl-ark closed an issue: "Prune-to mode (removable blockchain storage)"
(https://github.com/bitcoin/bitcoin/issues/10929)
(https://github.com/bitcoin/bitcoin/issues/10929)
💬 willcl-ark commented on issue "Prune-to mode (removable blockchain storage)":
(https://github.com/bitcoin/bitcoin/issues/10929#issuecomment-2047717121)
The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.
Pull requests with improvements are always welcome.
(https://github.com/bitcoin/bitcoin/issues/10929#issuecomment-2047717121)
The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.
Pull requests with improvements are always welcome.
💬 willcl-ark commented on issue "listsinceblock incorrectly showing some conflicted transactions":
(https://github.com/bitcoin/bitcoin/issues/10656#issuecomment-2047727910)
@ishaanam is this fixed by your recent mempool conflicted PR?
(https://github.com/bitcoin/bitcoin/issues/10656#issuecomment-2047727910)
@ishaanam is this fixed by your recent mempool conflicted PR?
💬 willcl-ark commented on issue "Add "effective fee rate" in rpc's mempool entries":
(https://github.com/bitcoin/bitcoin/issues/10389#issuecomment-2047733917)
Ping @murchandamus, does this work with MiniMiner now?
(https://github.com/bitcoin/bitcoin/issues/10389#issuecomment-2047733917)
Ping @murchandamus, does this work with MiniMiner now?
💬 glozow commented on issue "Add "effective fee rate" in rpc's mempool entries":
(https://github.com/bitcoin/bitcoin/issues/10389#issuecomment-2047741492)
> Ping @murchandamus, does this work with MiniMiner now?
It does, can probably implement this for `getmempoolentry`. Just need to handle `GatherClusters` potentially running up against the mempool limit.
(https://github.com/bitcoin/bitcoin/issues/10389#issuecomment-2047741492)
> Ping @murchandamus, does this work with MiniMiner now?
It does, can probably implement this for `getmempoolentry`. Just need to handle `GatherClusters` potentially running up against the mempool limit.
💬 maflcko commented on pull request "[DO NOT MERGE] testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2047753470)
> Is it really realistic that someone with just their CPU would be able to mine a block
Yes, I am not sure what would be the problem. All you have to do is to set the time +20min and mine a block on your laptop. If you don't want to try it yourself, you can come by to watch it on my laptop.
> Since some people consider the blockstorms an interesting feature of Testnet3
After a quick chat with @murchandamus, an alternative fix would be to require the pre-retarget block to have the "c
...
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2047753470)
> Is it really realistic that someone with just their CPU would be able to mine a block
Yes, I am not sure what would be the problem. All you have to do is to set the time +20min and mine a block on your laptop. If you don't want to try it yourself, you can come by to watch it on my laptop.
> Since some people consider the blockstorms an interesting feature of Testnet3
After a quick chat with @murchandamus, an alternative fix would be to require the pre-retarget block to have the "c
...
💬 willcl-ark commented on issue "rpc: Wrong `gettransaction` info for a coinjoin":
(https://github.com/bitcoin/bitcoin/issues/14136#issuecomment-2047754057)
@achow101 is this still a problem with descriptor wallets?
(https://github.com/bitcoin/bitcoin/issues/14136#issuecomment-2047754057)
@achow101 is this still a problem with descriptor wallets?
✅ 0xB10C closed an issue: "Discussion: Potential USDTs (User Static Defined Traces) for Core "
(https://github.com/bitcoin/bitcoin/issues/20981)
(https://github.com/bitcoin/bitcoin/issues/20981)