📝 fanquake locked a pull request: "Create bitcoin56"
(https://github.com/bitcoin/bitcoin/pull/27966)
<!--
*** 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
...

📝 mohammadimtayaj052 opened a pull request: "Create bitcoinBTC"
(https://github.com/bitcoin/bitcoin/pull/27967)
<!--
*** 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
...

💬 mohammadimtayaj052 commented on pull request "Create bitcoinBTC":
(https://github.com/bitcoin/bitcoin/pull/27967#issuecomment-1606145315)
btcaa

✅ hebasto closed a pull request: "Create bitcoinBTC"
(https://github.com/bitcoin/bitcoin/pull/27967)

📝 hebasto locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/27967)
<!--
*** 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
...

💬 Macoophonic commented on pull request "feerate: For GetFeePerK() return nSatoshisPerK instead of round trip through GetFee":
(https://github.com/bitcoin/bitcoin/pull/27914#issuecomment-1606183319)
Guys, it's late, I'll send more tomorrow 🤣🤣🤣😂
Hey gold night



Vào 21:56, CN, 25 thg 6, 2023 Matias Furszyfer ***@***.***>
đã viết:

> ***@***.**** approved this pull request.
>
> Code ACK 11d6500
> <https://github.com/bitcoin/bitcoin/commit/11d650060aed25273d860baa4e03168a778832bb>
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/pull/27914#pullrequestreview-1497104793>,
> or unsubscribe
> <https://github.com/notifications/unsub
...

💬 Macoophonic commented on issue "bitcoind hangs waiting for `g_requests.empty()`":
(https://github.com/bitcoin/bitcoin/issues/27722#issuecomment-1606197612)
Guys, it's late, I'll send more tomorrow 🤣🤣🤣😂
Hey gold night


Vào 21:15, CN, 25 thg 6, 2023 pablomartin4btc ***@***.***> đã
viết:

> As @willcl-ark <https://github.com/willcl-ark>, tried @theStack
> <https://github.com/theStack>'s method with no sucess, my libevent
> version is 2.1.7, I'll try to update it and retry again. Thanks.
>
> @Crypt-iQ <https://github.com/Crypt-iQ> I did: Ctrl-C the
> waitforblockheight command before trying to stop bitcoind.
>
> —
> Reply to this em
...

💬 Macoophonic commented on issue "deadlock shutting down v25.0":
(https://github.com/bitcoin/bitcoin/issues/27965#issuecomment-1606198010)
Guys, it's late, I'll send more tomorrow 🤣🤣🤣😂
Hey gold night


Vào 20:35, CN, 25 thg 6, 2023 Chris Moore ***@***.***> đã
viết:

> Netstat tells me there's nothing listening on port 8332:
>
> $ sudo netstat -plnt | grep 833
> tcp 0 0 127.0.0.1:8333 0.0.0.0:* LISTEN 584775/bitcoin-qt-v
> tcp 27 0 127.0.0.1:8334 0.0.0.0:* LISTEN 584775/bitcoin-qt-v
>
> Detaching gdb and running strace -f on the process s
...

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1241259654)
updated

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1241259892)
done

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1241259991)
changed to array, so this is no longer relevant

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#issuecomment-1606212309)
updates with latest push: changed the data structure to an array, indexed by the net message types & protected by the `m_nodes_mutex`. thanks for the thoughtful reviews! curious to hear thoughts on this new approach

💬 joostjager commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#issuecomment-1606255813)
@luke-jr annex covenants, see link in PR description

📝 ismaelsadeeq opened a pull request: "bumpfee: ignore WALLET_INCREMENTAL_RELAY_FEE when user specifies fee_rate "
(https://github.com/bitcoin/bitcoin/pull/27969)
Fixes #26973

When using the `bumpfee` RPC and manually specifying `fee_rate`, there should be no requirement that the new fee must be at least the sum of the original fee and `incrementalFee` (maximum of `relayIncrementalFee` and `WALLET_INCREMENTAL_RELAY_FEE`).

This restriction should only apply when user did not specify `fee_rate`.
> because the GUI doesn't let the user specify the new fee rate yet (https://github.com/bitcoin-core/gui/issues/647), it would be very annoying to have to bu
...

🤔 ariard reviewed a pull request: "policy: make unstructured annex standard"
(https://github.com/bitcoin/bitcoin/pull/27926#pullrequestreview-1497263042)
IIRC from #19645 and beyond, witnesses could be concatenate on the flight by transaction-relaying node, therefore ensuring the best feerate transaction propagates. As it’s opening it’s own wormhole of DoS issues, better to pursue the conversation on the mailing list.

💬 ariard commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241353751)
I think it makes sense to have a `annexrelay` option in `src/init.cpp` with `DEFAULT_ANNEXRELAY_ENABLE=false`, therefore to have node operators running nodes on performance-constrained hosts to opt-out from DoS concerns arising from the processing of the annex itself.

💬 ariard commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241352665)
I think we can constify the value, e.g `PER_INPUT_MAX_ANNEX_SIZE`, generally this is unclear if we would like a per-input annex limit and a max transaction all annexes limits, e.g `MAX_ANNEX_BUDGET`.

Splitting the limit enables flow where inputs can be combined in a non-deterministic order, e.g BIP174’s [combiner](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#combiner), and reject in function of “witness weight slots” that can be distributed by such combiner, which makes sens
...

💬 ariard commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241355849)
Should we introduce a limit on the number of inputs supported in a transaction opted-in annex ? To make it easier to reason on worst-case scenario from a second-layer perspective in case of multi-party flow e.g dual-funding. This number of inputs could be tied to the transaction’s `nVersion` field.

💬 ariard commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241344893)
I think here we might prefer to _not_ discount the 0x00 signaling byte from the 265 byte anti-annex-inflation-attacks limit, otherwise it sounds to me we’re introducing a coupling effect between the max witness size one can sign for and the tag signaling byte format itself. Such tag signaling byte format might acquire consensus semantic in the future, and I think we would prefer to reserve the evolvability in function of consensus changes here.

💬 ariard commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#discussion_r1241358413)
If we can move the annex policy-only code in its own `src/policy/annex` like we have at the image of `src/policy/packages.h` for code modularity. I think in the discussion of [#1381](https://github.com/bitcoin/bips/pull/1381) there has been question to reuse the annex in the future for [Grafroot](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html).