💬 crediblebytes commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1902643059)
With all due respect the "rough consensus" thing is shifting from representing the users of bitcoin to who has the most marketing dollars. In software development this means you are no longer building the "[right product](https://www.mojotech.com/blog/building-the-right-product-vs-building-the-product-right/)". The main use case is and always will be sound money. Not "freedom", "cypherpunk system", "database", or a "marketplace". This isn't your latest tech stack to build on. No go to AWS for th
...

🤔 furszy reviewed a pull request: "init: handle empty settings file gracefully"
(https://github.com/bitcoin/bitcoin/pull/29144#pullrequestreview-1835355513)
Rebased to cleanup spurious CI failure.

🤔 furszy reviewed a pull request: "wallet: simplify addressbook migration process"
(https://github.com/bitcoin/bitcoin/pull/26836#pullrequestreview-1835372627)
In response to feedback, the PR scope has been shortened, omitting the address book encapsulation commits. The current version includes only the subset of commits related to the address book from #28574. Decoupling this PR into two is also possible upon request.

👋 furszy's pull request is ready for review: "wallet: simplify addressbook migration process"
(https://github.com/bitcoin/bitcoin/pull/26836)

💬 furszy commented on pull request "wallet: optimize migration process, batch db transactions":
(https://github.com/bitcoin/bitcoin/pull/28574#issuecomment-1902683295)
Decoupled the address book cloning related commits to #26836.

📝 furszy converted_to_draft a pull request: "wallet: optimize migration process, batch db transactions"
(https://github.com/bitcoin/bitcoin/pull/28574)
The benchmark conducted locally showed a ~65% processing time reduction, on a SSD.
Results can be found at the end of the description.

#### Detailed Description:
The current wallet migration process performs only individual db writes. Accessing disk to
delete all legacy records, clone and clean each address book entry for every created wallet,
create each new descriptor (with their corresponding master key, caches and key pool), and
also clone and delete each transaction that requires to
...

💬 RobinLinus commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1902691540)
@eragmus seems to be an accomplice of the attacker, which might explain his use of extensive, convoluted texts filled with manipulative rhetoric, aimed at distracting from the attack.

@eragmus continually accuses me of cherry-picking statements, which is untrue. In reality, the attacker has even pinned a clip to his Twitter profile, bragging about ["polluting the UTXO set with toxic waste"](https://twitter.com/mikeinspace/status/1669467334145179649). Additionally, the attacker frequently rep
...

📝 achow101 locked a pull request: "set `DEFAULT_PERMIT_BAREMULTISIG` to false"
(https://github.com/bitcoin/bitcoin/pull/28217)
The default activation of the `permitbaremultisig=0` option proposes an enhancement for the Bitcoin network. By refusing non-P2SH multisignature transactions from the outset, this modification would contribute to reducing spam attempts and maintaining a healthy decentralization by discouraging undesirable activities.

💬 achow101 commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1902697653)
Keep discussion here civil or take your discussion somewhere else. Locking this as too heated for now.

⚠️ mjdietzx opened an issue: "Build error on macOS, tag v26.0 builds fine"
(https://github.com/bitcoin/bitcoin/issues/29289)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I can't build master on macOS, specifically when I include legacy wallet support

### Expected behaviour

Builds fine when I checkout tag v26.0. I don't remember getting this error in the past

### Steps to reproduce

Both build commands I've tried result in this error (I think I only get this error when I build w/ legacy wallet support, but don't fully remember):

```sh
./autogen.sh &&
...

📝 s1Sharp opened a pull request: "refactor: Readable widget naming for debug window"
(https://github.com/bitcoin-core/gui/pull/790)
Fixed widget names in the debug window. Make it more developer friendly to avoid confusion inside Qt Designer.

💬 s1Sharp commented on pull request "refactor: Readable widget naming for debug window":
(https://github.com/bitcoin-core/gui/pull/790#issuecomment-1902752609)
Qt Designer view before changes:
Qt Designer view after changes:

And a few changes for other widget names that were not included in the screenshots

💬 ajtowns commented on pull request "test: Add test case for spending bare multisig":
(https://github.com/bitcoin/bitcoin/pull/29120#issuecomment-1902869601)
> I compiled with #28217, which sets default value of `permitbaremultisig` to false in `policy.h` and tried to run this test case with `'allowed': False` for expected result but the test fails. I would have expected that one to pass the test.

The test case already explicitly sets `permitbaremultisig=0`, so changing the default should have no effect. These spends should always be allowed, so if you change the test to assert that it's not allowed, the test should fail.

🤔 ajtowns reviewed a pull request: "v3 transaction policy for anti-pinning"
(https://github.com/bitcoin/bitcoin/pull/28948#pullrequestreview-1835540987)
I find myself continually forgetting what the v3 rules are (particularly vs the ephemeral anchor rules, package relay rules, cluster mempool rules, or potential v4+ rules). It would be nice to have a really concise reference, that leaves the rationales/comparisons to an appendix or something. I think when stripped of historical baggage, it only needs to be:

unconfirmed v3 transactions:
* are always subject to rbf rules
* can have at most one unconfirmed v3 ancestor or one unconfirmed v3 d
...

💬 ajtowns commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1461286728)
Perhaps this should be "An **unconfirmed** V3 transaction cannothave more than 1 unconfirmd descendent" ?

💬 ajtowns commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1461284621)
It might be interesting to relax these rules to be:
* A v3 transaction can have a max descendent count of 5 (not 2)
* A v3 transaction with an ancestor count of two or more can have a maximum (sigop-adjusted) descendant size of 1000vb
* A v3 transaction can have at most 1 unconfirmed parent (rather than limiting ancestor count to at most 2)

(where ancestor/descendent size/count includes itself)

💬 ajtowns commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1461338849)
This seems underspecified: what's the behaviour if you have a v3 transaction in the mempool, with two or more outputs, one of which is spent by another v3 in-mempool transaction, and another (extremely high fee) transaction comes in, spending the other output?

Is it first-come-first-served, making descendent-count-pinning much easier? Or is it "we'll swap the old for the new if it has a better feerate diagram"? Or something else?

💬 stratospher commented on issue "Intermittent CI failure "fee too high" in wallet_send.py":
(https://github.com/bitcoin/bitcoin/issues/25164#issuecomment-1903232885)
happened here too: https://cirrus-ci.com/task/4577902440742912?logs=ci#L2654

💬 maflcko commented on issue "Build error on macOS, tag v26.0 builds fine":
(https://github.com/bitcoin/bitcoin/issues/29289#issuecomment-1903399940)
Which version of clang are you using?

You'll have to use at least version 13 or 14, depending on your build settings, but an even later version would be better.

💬 S3RK commented on pull request "wallet, rpc: `FundTransaction` refactor":
(https://github.com/bitcoin/bitcoin/pull/28560#issuecomment-1903507665)
According to my `range-diff` nothing changed.
reACK 18ad1b9142e91cef2f5c6a693eeb2d0fbb8c517d