💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186461359)
Fixed

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186460872)
Would it be API-breaky to change the result of prioritisetransaction?

I've edited the logs though, to show whether the tx is in mempool and what the new delta is. Btw I don't think `nTransactionsUpdated` starts out at 0 when this is called.

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186461032)
Done

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186459024)
Removed

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186459071)
Fixed

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186459143)
Taken

💬 glozow commented on pull request "mempool / rpc: add getprioritisationmap, delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/27501#discussion_r1186461262)
Done, added a `std::optional<CAmount> modified_fee` to the `delta_info` struct

💬 udiWertheimer commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536733105)
> taproot was designed with specific goals in mind to allow people to do whatever they want, as long as they aren't causing systemic issues with relay/validation/miners.
>
> On the other hand, legacy script is full of DoS disasters(that we can't simply softfork out because literal _theft_), and we shouldn't just open the gates further for people to trash the network.

Admittedly I wasn’t aware of that distinction between taproot and pre-taproot scripts wrt DoS issues. That’s good news! If t
...

💬 TheCharlatan commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#issuecomment-1536739318)
Rebased e056d6f758382d3418682095ab02f8d487aa641f -> 3b34ac7465919b968795063995f6610a73aa2d29 ([removeBlockstorageArgs_20](https://github.com/TheCharlatan/bitcoin/tree/removeBlockstorageArgs_20) -> [removeBlockstorageArgs_21](https://github.com/TheCharlatan/bitcoin/tree/removeBlockstorageArgs_21), [compare](https://github.com/TheCharlatan/bitcoin/compare/removeBlockstorageArgs_20..removeBlockstorageArgs_21))
* Fixed conflicts with #27570
* Added a commit to remove the params argument from the f
...

💬 TheCharlatan commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#issuecomment-1536750187)
Rebased 7d361083d72a267de4af258e574219abdef0fc82 -> dd95e2a3353b5ded87d1d5408a51bf461f1f90b4 ([kernelChainType_2](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_2) -> [kernelChainType_3](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_3), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelChainType_2..kernelChainType_3))
* Fixed conflict with #27570

🤔 mzumsande reviewed a pull request: "fuzz: BIP 42, BIP 30, CVE-2018-17144"
(https://github.com/bitcoin/bitcoin/pull/17860#pullrequestreview-1415372134)
Tested ACK fa2d8b61f9343d350b67357a12f39b613c8ee8ad

I was also able to catch the reintroduced CVE-2018-17144 (with the previous commit fa18fe3976a0f99480ce42dc0c1df7143967bf4d, current one is still running).

I can't really see how this actually fuzzes BIP42. Wouldn't the fuzzer need to create millions of blocks to detect it, so if we'd introduce that bug, the fuzzer would never be able to find it in practice?

Finally, I also observed that the fuzzer gets slower with time and after a few
...

💬 mzumsande commented on pull request "fuzz: BIP 42, BIP 30, CVE-2018-17144":
(https://github.com/bitcoin/bitcoin/pull/17860#discussion_r1186451948)
why is this check inside the `was_valid` branch?
As far as I understand it, the second block with the duplicate coinbase could be valid (if the coinbase from block 1 was spent), or BIP-30 invalid (otherwise) - but this should hold regardless.

💬 instagibbs commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536754509)
@udiWertheimer Assuming we could switch behavior ahead of time based on all inputs being taproot(it's a little more complicated in practice because other inputs might be ok too), I think the main drawback is optimization of the bin packing problem with larger items. Smaller items are easier to pick closer to optimally. This would fall under "keeping miners simple for decentralization" bucket instead of DoS.

💬 berenddeboer commented on issue "[Linux] Add wayland support":
(https://github.com/bitcoin/bitcoin/issues/19950#issuecomment-1536761117)
> Is it the case that our bitcion-qt release binaries don't work on Wayland at all?

All I can say that on Ubuntu 23.04 + Sway (which uses Wayland), bitcoin-qt does not work, and crashes with:

```
> bitcoin-core.qt
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Fontconfig warning: FcPattern object weight does not accept value [0 205)
fish: Job 1, 'bitcoin-core.qt' terminated by signal SIGSEGV (Address boundary error)
```

D
...

💬 achow101 commented on pull request "rpc: add `descriptorprocesspsbt` rpc":
(https://github.com/bitcoin/bitcoin/pull/25796#discussion_r1186505286)
In 80f8bdfeb3d9301e0aec4b797689cbe569eff5a6 "test: add test for `descriptorprocesspsbt` RPC"

This sync is failing due to an earlier unconfirmed transaction not persisting after the restart. A possible fix is to generate a block before restarting ndoe 2.

💬 benthecarman commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536797084)
> This would fall under "keeping miners simple for decentralization" bucket instead of DoS.

You could argue the opposite is happening though, the miners that are accommodating these transactions are making a killing right now because they have exclusive access to these large transactions.

💬 udiWertheimer commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1536805620)
> > This would fall under "keeping miners simple for decentralization" bucket instead of DoS.
>
> You could argue the opposite is happening though, the miners that are accommodating these transactions are making a killing right now because they have exclusive access to these large transactions.

Yes and, referring back to @sdaftuar’s point, one reason to include a flag to disable standardness rules would be to make life easier for such mining pools. Otherwise they have to modify and rebuild
...

💬 0xB10C commented on pull request "ci: fix asan task name":
(https://github.com/bitcoin/bitcoin/pull/27584#issuecomment-1536905657)
ACK


ref #27360

💬 ajtowns commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1186579724)
Rather than doing this, it might make more sense to have simplified relay logic be to send the messages:

* VERSION
* [after receiving VERSION] VERACK
* [after receiving VERACK] INV
* [after receiving GETDATA] TX
* PING
* [after receiving PONG] disconnect

?

⚠️ ajtowns opened an issue: "CPU DoS on mainnet in debug mode"
(https://github.com/bitcoin/bitcoin/issues/27586)
I've been seeing 100% cpu usage on one of my bitcoind nodes recently, with transactions taking >60s to be accepted into the mempool. Digging into it, the problem seems to be `BOOST_MULTI_INDEX_ENABLE_SAFE_MODE` which was introduced in #24395. That results in iterator destruction taking O(n) time (in the number of other active iterators on the same multi-index) in the worst case, rather than O(1) time, due to keeping the iterators in a [singly linked list](https://www.boost.org/doc/libs/1_82_0/b
...