🤔 BrandonOdiwuor reviewed a pull request: "test: p2p: check disconnect due to lack of desirable service flags"
(https://github.com/bitcoin/bitcoin/pull/29279#pullrequestreview-1833607389)
Concept ACK 358561e54ef84f64b216ca8a4271ad17d91b1d51
Increasing code coverage
(https://github.com/bitcoin/bitcoin/pull/29279#pullrequestreview-1833607389)
Concept ACK 358561e54ef84f64b216ca8a4271ad17d91b1d51
Increasing code coverage
💬 hebasto commented on pull request "Avoid non-self-contained Windows header":
(https://github.com/bitcoin-core/gui/pull/789#issuecomment-1901046564)
Friendly ping @sipsorcery :)
(https://github.com/bitcoin-core/gui/pull/789#issuecomment-1901046564)
Friendly ping @sipsorcery :)
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709324)
done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709324)
done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709417)
done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709417)
done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709496)
done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709496)
done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709630)
done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709630)
done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709663)
looks good, done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709663)
looks good, done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709766)
done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709766)
done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709852)
done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709852)
done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709932)
done
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459709932)
done
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459710174)
makes sense, moved
(https://github.com/bitcoin/bitcoin/pull/29242#discussion_r1459710174)
makes sense, moved
💬 murchandamus commented on pull request "Add max_tx_weight to transaction funding options":
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1459729161)
It would be better to make `max_input_weight` a fuzzed value.
(https://github.com/bitcoin/bitcoin/pull/29264#discussion_r1459729161)
It would be better to make `max_input_weight` a fuzzed value.
📝 sipa opened a pull request: "Choose earliest-activatable as tie breaker between equal-work chains"
(https://github.com/bitcoin/bitcoin/pull/29284)
### Current logic
Since #3370, our logic for deciding which chain is active has been:
1. Among chains for which all transactions have been received, and are not known to contain invalid blocks...
2. Pick the one with the highest accumulated work
3. If there are multiple such chaintips, pick the one for which the tip was received first (full block data, not just the header)
The reason for this last condition is protecting against block withholding. If an attacker manages to mine a block,
...
(https://github.com/bitcoin/bitcoin/pull/29284)
### Current logic
Since #3370, our logic for deciding which chain is active has been:
1. Among chains for which all transactions have been received, and are not known to contain invalid blocks...
2. Pick the one with the highest accumulated work
3. If there are multiple such chaintips, pick the one for which the tip was received first (full block data, not just the header)
The reason for this last condition is protecting against block withholding. If an attacker manages to mine a block,
...
💬 sipsorcery commented on pull request "Avoid non-self-contained Windows header":
(https://github.com/bitcoin-core/gui/pull/789#issuecomment-1901146553)
utACK c95767aa68e9e0e71e76884dbc83d237afdd7a37.
(https://github.com/bitcoin-core/gui/pull/789#issuecomment-1901146553)
utACK c95767aa68e9e0e71e76884dbc83d237afdd7a37.
💬 instagibbs commented on pull request "Mempool util: Add RBF diagram checks for single chunks against clusters of size 2":
(https://github.com/bitcoin/bitcoin/pull/29242#issuecomment-1901152779)
test failure appears to be spurious wallet failure, ready for review
(https://github.com/bitcoin/bitcoin/pull/29242#issuecomment-1901152779)
test failure appears to be spurious wallet failure, ready for review
💬 furszy commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1459907359)
> > The node's contextual information and logic required to take the decision of opening a socket to a particular address resides mostly in PeerManager (right now, we only have the stale chain condition, but there could be more)
>
> This is not true? [`ThreadOpenConnections`](https://github.com/bitcoin/bitcoin/blob/03c5b0064d4f766bc8dc6508773c7579e9ad39bc/src/net.cpp#L2415) is a method on `CConnman` and handles the opening of network connections.
Yes, that's the layering violation that cau
...
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1459907359)
> > The node's contextual information and logic required to take the decision of opening a socket to a particular address resides mostly in PeerManager (right now, we only have the stale chain condition, but there could be more)
>
> This is not true? [`ThreadOpenConnections`](https://github.com/bitcoin/bitcoin/blob/03c5b0064d4f766bc8dc6508773c7579e9ad39bc/src/net.cpp#L2415) is a method on `CConnman` and handles the opening of network connections.
Yes, that's the layering violation that cau
...
🤔 mzumsande reviewed a pull request: "fuzz: extend ConsumeNetAddr() to return I2P and CJDNS addresses"
(https://github.com/bitcoin/bitcoin/pull/26859#pullrequestreview-1833881229)
This doesn't play well with recent changes made in #27935:
That PR added the line
```
const std::optional<CNetAddr>& addr{LookupHost(net_addr.ToStringAddr(), /*fAllowLookup=*/false)};
```
to `fuzz/banman.cpp` , after which a randomly generated CJDNS address would be changed to IPv6, and then the fuzz target fails. It takes just a few seconds / minutes for the fuzzer to crash.
So it would be good to rebase this branch and fix that issue.
(https://github.com/bitcoin/bitcoin/pull/26859#pullrequestreview-1833881229)
This doesn't play well with recent changes made in #27935:
That PR added the line
```
const std::optional<CNetAddr>& addr{LookupHost(net_addr.ToStringAddr(), /*fAllowLookup=*/false)};
```
to `fuzz/banman.cpp` , after which a randomly generated CJDNS address would be changed to IPv6, and then the fuzz target fails. It takes just a few seconds / minutes for the fuzzer to crash.
So it would be good to rebase this branch and fix that issue.
💬 ryanofsky commented on pull request "depends: Update libmultiprocess library to fix C++20 macos build error":
(https://github.com/bitcoin/bitcoin/pull/29276#issuecomment-1901253716)
There is another macos issue I'm debugging here: https://github.com/chaincodelabs/libmultiprocess/issues/92 and I don't think it shows up in depends builds because the depends build skips tests. But it might trigger errors in bitcoin builds if more code from #10102 is merged.
There is no need to hold off on this PR, but if it is not merged, I will probably update it again with whatever the fix is for https://github.com/chaincodelabs/libmultiprocess/issues/92
I probably need to figure out a
...
(https://github.com/bitcoin/bitcoin/pull/29276#issuecomment-1901253716)
There is another macos issue I'm debugging here: https://github.com/chaincodelabs/libmultiprocess/issues/92 and I don't think it shows up in depends builds because the depends build skips tests. But it might trigger errors in bitcoin builds if more code from #10102 is merged.
There is no need to hold off on this PR, but if it is not merged, I will probably update it again with whatever the fix is for https://github.com/chaincodelabs/libmultiprocess/issues/92
I probably need to figure out a
...
💬 eragmus commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1901258102)
> I think this view shows a twisted absolute ignorance of what Bitcoin is about. Different from "crypto", Bitcoin is not an "all purpose DB" neither a 'world computer'. Its scope must be instead, contrary to all the 10000 altcoining misconceptions, and be kept tyranically (Satoshi's used term on this) TINY. Fees in Bitcoin are one of the measures against arbitrary data dumping, and Satoshi mentioned 'OTHER THINGS' that he could do to actually FIGHT it, NOT by any means EVER accept such misuse ou
...
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1901258102)
> I think this view shows a twisted absolute ignorance of what Bitcoin is about. Different from "crypto", Bitcoin is not an "all purpose DB" neither a 'world computer'. Its scope must be instead, contrary to all the 10000 altcoining misconceptions, and be kept tyranically (Satoshi's used term on this) TINY. Fees in Bitcoin are one of the measures against arbitrary data dumping, and Satoshi mentioned 'OTHER THINGS' that he could do to actually FIGHT it, NOT by any means EVER accept such misuse ou
...
💬 eragmus commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1901272351)
> > Which of these [opcodes](https://en.bitcoin.it/wiki/Script#Opcodes) is not working as implemented or [documented](https://github.com/ChrisCho-H/bitcoin/blob/0bf55345764d22c5653c0a374647aa5582a186a2/src/script/script.h)?
>
> It's not a single opcode that is not working as implemented or documented. It's the whole system that is not behaving as expected.
>
> If you have an API so users of your site can upload pictures for blog posts, and you found that somebody uploaded a 35 GB blueray-r
...
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1901272351)
> > Which of these [opcodes](https://en.bitcoin.it/wiki/Script#Opcodes) is not working as implemented or [documented](https://github.com/ChrisCho-H/bitcoin/blob/0bf55345764d22c5653c0a374647aa5582a186a2/src/script/script.h)?
>
> It's not a single opcode that is not working as implemented or documented. It's the whole system that is not behaving as expected.
>
> If you have an API so users of your site can upload pictures for blog posts, and you found that somebody uploaded a 35 GB blueray-r
...