👍 hebasto approved a pull request: "ci: remove duplicate bsdmainutils from CI configs"
(https://github.com/bitcoin/bitcoin/pull/27987#pullrequestreview-1502765481)
ACK 248a17addf3cb519cb5e0fb91b9f25ce8d003d85
(https://github.com/bitcoin/bitcoin/pull/27987#pullrequestreview-1502765481)
ACK 248a17addf3cb519cb5e0fb91b9f25ce8d003d85
💬 carnhofdaki commented on issue "Add maxrelaytxfee":
(https://github.com/bitcoin/bitcoin/issues/27983#issuecomment-1611150049)
@MarcoFalke Thank you for feedback.
Last thing first: Yes, it does not make sense to implement it in the same way as `minrelaytxfee`. Such code would just add one more processing step to each transaction before it is broadcast further.
Back to your first concern: The miner may have a contract with someone who pays the fees for such recycling service off-chain.
In my view, a re-org _after_ the other miner (fee-sniper) gets the block from the P2P network and uses its all-fee transaction i
...
(https://github.com/bitcoin/bitcoin/issues/27983#issuecomment-1611150049)
@MarcoFalke Thank you for feedback.
Last thing first: Yes, it does not make sense to implement it in the same way as `minrelaytxfee`. Such code would just add one more processing step to each transaction before it is broadcast further.
Back to your first concern: The miner may have a contract with someone who pays the fees for such recycling service off-chain.
In my view, a re-org _after_ the other miner (fee-sniper) gets the block from the P2P network and uses its all-fee transaction i
...
📝 MarcoFalke opened a pull request: "test: Use same timeout for all index sync"
(https://github.com/bitcoin/bitcoin/pull/27988)
Seems odd to use different timeouts.
Fix this by using the same timeout for all syncs.
May also fix ?
(https://github.com/bitcoin/bitcoin/pull/27988)
Seems odd to use different timeouts.
Fix this by using the same timeout for all syncs.
May also fix ?
📝 hebasto opened a pull request: "refactor: Move sock from util to common"
(https://github.com/bitcoin/bitcoin/pull/27989)
Networking code should not be required by the kernel.
(https://github.com/bitcoin/bitcoin/pull/27989)
Networking code should not be required by the kernel.
💬 MarcoFalke commented on issue "index: ThreadSanitizer: data race on vptr ":
(https://github.com/bitcoin/bitcoin/issues/27355#issuecomment-1611154752)
This is getting too frequent. I recently encountered this 8 times in a row.
Maybe https://github.com/bitcoin/bitcoin/pull/27988 makes it less frequent for now, by only modifying test code?
(https://github.com/bitcoin/bitcoin/issues/27355#issuecomment-1611154752)
This is getting too frequent. I recently encountered this 8 times in a row.
Maybe https://github.com/bitcoin/bitcoin/pull/27988 makes it less frequent for now, by only modifying test code?
👍 fanquake approved a pull request: "guix: Update `python-lief` package to 0.13.2"
(https://github.com/bitcoin/bitcoin/pull/27813#pullrequestreview-1502778035)
ACK 529c92e837b28169b501562efe7b5b7120a2ebbb
(https://github.com/bitcoin/bitcoin/pull/27813#pullrequestreview-1502778035)
ACK 529c92e837b28169b501562efe7b5b7120a2ebbb
💬 MarcoFalke commented on issue "Add maxrelaytxfee":
(https://github.com/bitcoin/bitcoin/issues/27983#issuecomment-1611162386)
> The miner may have a contract with someone who pays the fees for such recycling service off-chain.
If the fee is paid off-chain anyway and doesn't exists within the tx, then this whole feature request doesn't make sense either, because there is no fee to check.
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.co
...
(https://github.com/bitcoin/bitcoin/issues/27983#issuecomment-1611162386)
> The miner may have a contract with someone who pays the fees for such recycling service off-chain.
If the fee is paid off-chain anyway and doesn't exists within the tx, then this whole feature request doesn't make sense either, because there is no fee to check.
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.co
...
🚀 fanquake merged a pull request: "guix: Update `python-lief` package to 0.13.2"
(https://github.com/bitcoin/bitcoin/pull/27813)
(https://github.com/bitcoin/bitcoin/pull/27813)
💬 stickies-v commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1242236262)
nit: no need to use a C-style string here I think
```suggestion
const std::string err{"URI parsing failed, it likely contained RFC 3986 invalid characters"};
```
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1242236262)
nit: no need to use a C-style string here I think
```suggestion
const std::string err{"URI parsing failed, it likely contained RFC 3986 invalid characters"};
```
💬 stickies-v commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1243780038)
Do we need this?
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1243780038)
Do we need this?
💬 stickies-v commented on pull request "httpserver, rest: improving URI validation":
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1245038873)
I don't think it's great that we're not doing the address-based checks before anything else. Since we're now adding validation into the constructor, how about we do it consistently and do it for all validation, so we can also control what we validate first? I'm still feeling a bit uneasy about coupling the construction of `HTTPRequest` with validation, but if we're doing it we might as well do it more consistently? Curious to hear @vasild's thoughts on this too.
<details>
<summary>git diff</
...
(https://github.com/bitcoin/bitcoin/pull/27253#discussion_r1245038873)
I don't think it's great that we're not doing the address-based checks before anything else. Since we're now adding validation into the constructor, how about we do it consistently and do it for all validation, so we can also control what we validate first? I'm still feeling a bit uneasy about coupling the construction of `HTTPRequest` with validation, but if we're doing it we might as well do it more consistently? Curious to hear @vasild's thoughts on this too.
<details>
<summary>git diff</
...
💬 MarcoFalke commented on pull request "init: return error when block index is non-contiguous, fix feature_init.py file perturbation":
(https://github.com/bitcoin/bitcoin/pull/27823#issuecomment-1611186437)
Could rebase for CI?
(https://github.com/bitcoin/bitcoin/pull/27823#issuecomment-1611186437)
Could rebase for CI?
💬 MarcoFalke commented on pull request "refactor: Continue moving application data from CNode to Peer":
(https://github.com/bitcoin/bitcoin/pull/26621#issuecomment-1611188048)
Needs rebase if still relevant
(https://github.com/bitcoin/bitcoin/pull/26621#issuecomment-1611188048)
Needs rebase if still relevant
💬 MarcoFalke commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#issuecomment-1611189572)
Could rebase for CI?
(https://github.com/bitcoin/bitcoin/pull/27675#issuecomment-1611189572)
Could rebase for CI?
💬 MarcoFalke commented on pull request "wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction":
(https://github.com/bitcoin/bitcoin/pull/25273#issuecomment-1611191360)
Needs rebase if still relevant
(https://github.com/bitcoin/bitcoin/pull/25273#issuecomment-1611191360)
Needs rebase if still relevant
💬 fanquake commented on pull request "build: produce a .zip for macOS distribution":
(https://github.com/bitcoin/bitcoin/pull/27099#discussion_r1245046746)
Applied.
(https://github.com/bitcoin/bitcoin/pull/27099#discussion_r1245046746)
Applied.
💬 MarcoFalke commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#issuecomment-1611194968)
CI failure in feature_proxy.py:
https://cirrus-ci.com/task/4981950109188096?logs=ci#L5325
```
node0 stderr net.cpp:1142:113: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'value_type' (aka 'unsigned int')
#0 0x55dbd8047436 in CConnman::DisconnectNodes() src/net.cpp:1142:113
#1 0x55dbd807d233 in CConnman::ThreadSocketHandler() src/net.cpp:1393:9
#2 0x55dbd807d233 in CConnman::Start(CScheduler&, CConnman::Options const&)::$_1::operator()() con
...
(https://github.com/bitcoin/bitcoin/pull/27213#issuecomment-1611194968)
CI failure in feature_proxy.py:
https://cirrus-ci.com/task/4981950109188096?logs=ci#L5325
```
node0 stderr net.cpp:1142:113: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'value_type' (aka 'unsigned int')
#0 0x55dbd8047436 in CConnman::DisconnectNodes() src/net.cpp:1142:113
#1 0x55dbd807d233 in CConnman::ThreadSocketHandler() src/net.cpp:1393:9
#2 0x55dbd807d233 in CConnman::Start(CScheduler&, CConnman::Options const&)::$_1::operator()() con
...
💬 vasild commented on pull request "test: remove race in the user-agent reception check":
(https://github.com/bitcoin/bitcoin/pull/27986#issuecomment-1611195730)
`44d71cfd0e...9c46f3ba19`: do https://github.com/bitcoin/bitcoin/pull/27986#discussion_r1244951363
(https://github.com/bitcoin/bitcoin/pull/27986#issuecomment-1611195730)
`44d71cfd0e...9c46f3ba19`: do https://github.com/bitcoin/bitcoin/pull/27986#discussion_r1244951363
💬 vasild commented on pull request "test: remove race in the user-agent reception check":
(https://github.com/bitcoin/bitcoin/pull/27986#discussion_r1245048980)
Done!
(https://github.com/bitcoin/bitcoin/pull/27986#discussion_r1245048980)
Done!
👍 fanquake approved a pull request: "http: update libevent workaround to correct version"
(https://github.com/bitcoin/bitcoin/pull/27949#pullrequestreview-1502843856)
ACK 79d343a642f985801da463b03a0627a59a095238
(https://github.com/bitcoin/bitcoin/pull/27949#pullrequestreview-1502843856)
ACK 79d343a642f985801da463b03a0627a59a095238