💬 vasild commented on issue "Does not use bind to local address for outgoing connections":
(https://github.com/bitcoin/bitcoin/issues/6476#issuecomment-1666472338)
This request looks reasonable. Is there still interest in it?

Something like this should do it (and pass the proper argument to `ConnectSocketDirectly()` untested):

```diff
-bool ConnectSocketDirectly(const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
+bool ConnectSocketDirectly(const std::optional<CNetAddr>& addr_from, const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
{
// Create a sockaddr from the specified s
...

💬 HenrikJannsen commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666475502)
> 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. For those reasons I'm actually in favor.. so ACK.

It is not only the financial costs one need to consider, there are other costs. Complexity of imple
...

💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1666478746)
> But I don't understand the numbers.

Me neither. See https://github.com/cirruslabs/cirrus-ci-web/pull/572#issuecomment-1666478538.

📝 fanquake locked a pull request: "Create devcontainer.json"
(https://github.com/bitcoin/bitcoin/pull/28219)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

💬 zndtoshi commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666485874)
An option would be also to keep status quo and let node runners modify bitcoin.conf if they want to increase the op_return limit. Like the discussion with fullmempoolrbf.

💬 zkfrio commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666488599)
> I don't understand why Bitcoin devs are not more engaged in those discussions.

Because nobody wants to attack the network because of some transactions.

💬 Retropex commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666492502)
@zkfrio Do you think that giving the choice of the mempool policy is attacking the network?

💬 Retropex commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1666494844)
> 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.

I know it, unfortunate
...

💬 zkfrio commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666496157)
> @zkfrio Do you think that giving the choice of the mempool policy is attacking the network?

I was responding to 'ordislow' related comment. It's an organized attack that would not improve anything.

💬 dergoegge commented on pull request "Use shared_ptr for CNode inside CConnman":
(https://github.com/bitcoin/bitcoin/pull/28222#issuecomment-1666508138)
Also see #10738

💬 petertodd commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666512036)
@HenrikJannsen

> Ideas like https://twitter.com/hashtag/ordislow with delaying blocks containing ordinals might be worth considering in more detail. I don't understand why Bitcoin devs are not more engaged in those discussions.

Bitcoin devs haven't engaged with those discussions because #ordislow is a dumb idea that is very unlikely to work; to the extent it does work, it will simply act to further centralize mining. #ordislow is fundamentally an attempt at censorship of blocks (informati
...

💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1666513527)
> why not focus efforts on reducing the need for Replace by Fee to begin with?

As I and others have explained above in the linked resources, eg https://petertodd.org/2023/fullrbf-multiparty-protocols and https://petertodd.org/2023/why-you-should-run-mempoolfullrbf, it is impossible to eliminate the need for transaction replacement.

💬 willcl-ark commented on pull request "Use shared_ptr for CNode inside CConnman":
(https://github.com/bitcoin/bitcoin/pull/28222#issuecomment-1666517688)
> Also see #10738

Thanks, I hadn't seen this one before. Will take a look tonight

💬 luke-jr commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666522472)
>Allows for including signature by a third party other than that signing the keys controlling the inputs. E.g., service provider.

🚩🚩🚩 Sounds like maybe this is tied to some kind of KYC nonsense?

There shouldn't be a "service provider" to begin with. (And if you really need such a signature, you could put it INSIDE the data which is being hashed.)

>People were putting garbage and "spamming" the blockchain in the past, spamming is rampant currently and I have never ever seen a convinci
...

💬 luke-jr commented on pull request "Bech32 LocateErrors "Bech32 string too short" case":
(https://github.com/bitcoin/bitcoin/pull/28160#issuecomment-1666526030)
The new error_locations looks worse/broken...

💬 luke-jr commented on pull request "refactor: Revert additional univalue check in ParseSighashString":
(https://github.com/bitcoin/bitcoin/pull/28162#discussion_r1285070240)
Might also want to catch it NOT throwing an error when it ought to.

💬 luke-jr commented on pull request "script: throw disabled err for op_ver and its variants":
(https://github.com/bitcoin/bitcoin/pull/28169#discussion_r1285070870)
How does OP_VER differ from a non-existent opcode?

💬 luke-jr commented on pull request "ParseHDKeypath: support h as hardened marker":
(https://github.com/bitcoin/bitcoin/pull/28192#issuecomment-1666530013)
Seems likely someone somewhere will want to combine two derivation paths, which might use different markers.

💬 achow101 commented on pull request "script: throw disabled err for op_ver and its variants":
(https://github.com/bitcoin/bitcoin/pull/28169#discussion_r1285078233)
It's actually defined and exists in documentation.

💬 luke-jr commented on pull request "mempool: Persist with XOR":
(https://github.com/bitcoin/bitcoin/pull/28207#issuecomment-1666541683)
Concept ACK, I don't think we need to concern with external programs reading this. If they do exist, they can adapt easily.