💬 dpc commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666383038)
OP_RETURN size limit is a "feel good" policy, that achieves nothing and just make things artificially more difficult in other areas. You'd think that Bitcoiners are going to be more rational than politicians that need to fool the public to get re-elected with such policies.

People were putting garbage and "spamming" the blockchain in the past, spamming is rampant currently and I have never ever seen a convincing explanation of a future strategy that could actually stop it. And no, ever increa
...

⚠️ darosior opened an issue: "Flaky `wallet_transactiontime_rescan.py --legacy-wallet` functional test"
(https://github.com/bitcoin/bitcoin/issues/28221)
Failed in CI on unrelated PR https://github.com/bitcoin/bitcoin/pull/28216.

```
test 2023-08-04T17:39:25.417000Z TestFramework (ERROR): Called Process failed with 'error: timeout on transient error: Could not connect to the server 127.0.0.1:20800 (error code 0 - "timeout reached")
Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
'
Traceba
...

💬 darosior commented on pull request "mempool: Persist with XOR":
(https://github.com/bitcoin/bitcoin/pull/28207#discussion_r1284973598)
Might as well set it to true, as long as someone who was relying on the previous behaviour can simply set `-persistmempoolv1`.

🤔 darosior reviewed a pull request: "mempool: Persist with XOR"
(https://github.com/bitcoin/bitcoin/pull/28207#pullrequestreview-1563779763)
Concept and approach ACK. I don't think there is harm in making it the default behaviour immediately.

💬 darosior commented on pull request "mempool: Persist with XOR":
(https://github.com/bitcoin/bitcoin/pull/28207#discussion_r1284973476)
```suggestion
DEFAULT_PERSIST_V1_DAT),
```

💬 hebasto commented on pull request "ci: Run Windows native task on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28173#issuecomment-1666430255)
Converting this PR to a draft as it conflicts with https://github.com/bitcoin/bitcoin/pull/28187.

Please review https://github.com/bitcoin/bitcoin/pull/28187 first.

📝 hebasto converted_to_draft a pull request: "ci: Run Windows native task on GitHub Actions"
(https://github.com/bitcoin/bitcoin/pull/28173)
From https://github.com/bitcoin/bitcoin/issues/28098:
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks.

> If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.

Historical context:
- https://github.com/bitcoin/bitcoin/pull/17697
- https://github.com/bitcoin/bitcoin/issues/17803
- https://github.com/bitcoin/bitcoin/pull/18031

Security concerns:
- https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-16514321
...

💬 zndtoshi commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666435919)
Did anyone calculate what would be the cost of placing ordinals inside a no-limit op_return output? If the costs would be higher (as I imagine) than putting them in the witness space (and taking advantage of the witness discount) then the merge of this proposal would not solve anything because people will just continue to use the cheapest way.

💬 TheCharlatan commented on pull request "kernel: Prune leveldb headers":
(https://github.com/bitcoin/bitcoin/pull/28186#discussion_r1284999471)
It would, but then we'd also have to forward-declare a destructor class for it and I don't think it's really worth doing that.

💬 dimitaracev commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666441956)
Concept NACK for the same reasons others have stated above.

📝 willcl-ark opened a pull request: "Use shared_ptr for CNode inside CConnman"
(https://github.com/bitcoin/bitcoin/pull/28222)
Switch to using smart pointers to `CNode`s inside of `CConnman`.

Currently we are manually refcounting CNodes which is potentially error-prone and makes operations such as deleting them from multiple threads difficult without introducing new locks or other synchronisation operations (see https://github.com/bitcoin/bitcoin/pull/27912).

Switch to using `std::shared_ptr` references to `CNode`s inside of `m_nodes` and `m_nodes_disconnected` to give us better memory safety today, and in the fut
...

💬 TheCharlatan commented on pull request "kernel: Prune leveldb headers":
(https://github.com/bitcoin/bitcoin/pull/28186#issuecomment-1666459887)
Thank you for the review @stickies-v,

Updated 3fb2dac2ce78092c1006ee082c536bea1b69a152 -> 1be04724a3ac061859118c09b90e2e15ea8d04b0 ([cleaveLeveldbHeaders_4](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_4) -> [cleaveLeveldbHeaders_5](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_5), [compare](https://github.com/TheCharlatan/bitcoin/compare/cleaveLeveldbHeaders_4..cleaveLeveldbHeaders_5))

* Addressed @stickies-v's [comment_1](https://github.com/bitco
...

💬 real-or-random commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666461727)
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks

How did you arrive at these numbers? Is there a better source than the [cirrus "metrics" page](https://cirrus-ci.com/metrics/repository/github/bitcoin/bitcoin)? I looked at this in the past for libsecp256k1 and arrived at very high USD numbers. Now I redid the numbers for Linux tasks and that's pretty cheap (for secp256k1):

Based on the graph in https://cirrus-ci.com/metrics/repository/github/bitcoin-co
...

💬 vostrnad commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666461731)
> Yes, that's a good thing because standard output types don't bloat the UTXO set as much as the current spam attacks do.

I admit I don't know the specifics of how the UTXO set is stored, but how does storing 96 bytes in one 3-of-3 bare multisig bloat it more than say storing it in 3 P2TR outputs?

💬 Retropex commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666462061)
> Best practices in accordance with whom?

With my node that has been constantly spamming for seven months with catastrophic consequences on the UTXOs set.

[Size of Serialized UTXO Set.](https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=10m&from=now-1y&to=now&viewPanel=8)

[Stamps.](https://orangepill.ovh/fr/tx/b06d85ba23e663d24e73041df4f708e030991377a36a300dd439e6bfa2f2eaa1)

💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666465022)
> > Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks
>
> How did you arrive at these numbers? Is there a better source than the [cirrus "metrics" page](https://cirrus-ci.com/metrics/repository/github/bitcoin/bitcoin)?

https://cirrus-ci.com/settings/github/bitcoin:


But "Monthly Usage" numbers in https://cirrus-ci.com/settings/github/bitcoin-core are no
...

💬 real-or-random commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666467850)
Oh, thanks, this was the page I couldn't find anymore. But I don't understand the numbers. For example for the "bitcoin" org, the page shows 3495 CPU hours and 3160 credits on Linux in July. How does this work out? 3495 h = 209700 min, which translates to 629,1 credits assuming 3 credits/1000 min.

💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666469027)
> Oh, thanks, this was the page I couldn't find anymore. But I don't understand the numbers. For example for the "bitcoin" org, the page shows 3495 CPU hours and 3160 credits on Linux in July. How does this work out? 3495 h = 209700 min, which translates to 629,1 credits assuming 3 credits/1000 min.

cc @fkorotkov

💬 Retropex commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#discussion_r1285019803)
PR updated.

Your changes worked on my side.

💬 vostrnad commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666471945)
The vast majority of the recent UTXO set size increase (which mostly happened in the last four months, not seven) comes not from [bare multisig](https://transactionfee.info/charts/inputs-and-outputs-p2ms/) but from [BRC-20](https://transactionfee.info/charts/inputs-and-outputs-p2tr/). Bare multisig peaked in April, barely crossing 10k unspent outputs a day, and currently adds only a few hundred daily, while BRC-20 still keeps adding over 50k unspent outputs every day.

Note that this is largel
...