Bitcoin Core Github
44 subscribers
121K links
Download Telegram
📝 defiminds opened a pull request: "Build file"
(https://github.com/bitcoin/bitcoin/pull/27535)
<!--
*** 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
...
defiminds closed a pull request: "Build file"
(https://github.com/bitcoin/bitcoin/pull/27535)
📝 defiminds opened a pull request: "build file"
(https://github.com/bitcoin/bitcoin/pull/27536)
<!--
*** 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
...
💬 rebroad commented on issue "add ability to remove (dust) UTXOs":
(https://github.com/bitcoin/bitcoin/issues/23875#issuecomment-1524863724)
I'm curious what algorithms you have in mind. How would you derive the
numbers used in this algorithm?[image:
dfd40693391154b2159adbf2cd30e6451e74f7b2]
​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

On Thu, 27 Apr 2023, 01:28 Peter Todd, ***@***.***> wrote:

> @rebroad <https://github.com/rebroad> The economic way to deal with dust
> UTXO's would be to soft-fork in a per-UTXO storage "tax", that eventually
> makes a UTXO unsepndable
...
MarcoFalke closed a pull request: "build file"
(https://github.com/bitcoin/bitcoin/pull/27536)
💬 MarcoFalke commented on pull request "Add `UNREACHABLE` macro and drop `-Wreturn-type`/`C4715` warnings suppressions":
(https://github.com/bitcoin/bitcoin/pull/26504#issuecomment-1524922834)
Concept ACK 🫠
💬 instagibbs commented on pull request "[POLICY] Ephemeral anchors":
(https://github.com/bitcoin/bitcoin/pull/26403#issuecomment-1524972854)
Should add a test showing that node restart dumps ephemeral transactions since re-admission to the mempool is done single tx by single tx only.
💬 MarcoFalke commented on pull request "rpc: Add importmempool RPC":
(https://github.com/bitcoin/bitcoin/pull/27460#issuecomment-1524999351)
The use case would be wanting to sync both the chain and the mempool to include everything/most known by the network or one of your other nodes. This is trivially possible for the chain, however for the mempool it is not.

One option would be to use the `mempool` P2P message type, or add a new message type. This would likely require lifting some restrictions or adding others to make it usable in a normal setting and still prevent privacy/DoS concerns. To what extent the existing `mempool` mess
...
⚠️ MarcoFalke opened an issue: "Drop support for g++-8?"
(https://github.com/bitcoin/bitcoin/issues/27537)
I am wondering when we can drop support for g++-8. All supported operating systems, except for CentOS Stream 8 offer a greater version:

* Ubuntu Focal: gcc 9 (https://packages.ubuntu.com/focal/gcc)
* Debian Bullseye: gcc 10 (https://packages.debian.org/bullseye/gcc)
* CentOS 8 Stream: gcc 8, with EOL of " May 31st, 2024 " (https://www.centos.org/centos-stream/)

The rationale for dropping it would be that there are currently occasional compile failures with perfectly valid C++-17 code, fo
...
💬 MarcoFalke commented on issue "Drop support for g++-8?":
(https://github.com/bitcoin/bitcoin/issues/27537#issuecomment-1525048924)
Added 27.0 for now, which should be uncontroversial.
💬 MarcoFalke commented on pull request "blockstorage: do not flush block to disk if it is already there":
(https://github.com/bitcoin/bitcoin/pull/27039#issuecomment-1525052314)
Maybe rebase to make CI less sad?
💬 laanwj commented on pull request "contrib: add ELF OS ABI check to symbol-check.py":
(https://github.com/bitcoin/bitcoin/pull/26953#discussion_r1178793152)
lets check `note.details.abi == lief.ELF.NOTE_ABIS.LINUX` as well
💬 laanwj commented on pull request "contrib: add ELF OS ABI check to symbol-check.py":
(https://github.com/bitcoin/bitcoin/pull/26953#issuecomment-1525096454)
Concept and code review ACK 407bad3f5e9a749bb344ad677036f22c2b70ea69 , left a nit
💬 laanwj commented on pull request "Add support for RNDR/RNDRRS for AArch64 on Linux":
(https://github.com/bitcoin/bitcoin/pull/26839#discussion_r1178799972)
nit: this whole block is in a `#ifdef __aarch64__` section so it's not necessary to re-check here
💬 MarcoFalke commented on pull request "test: perturb anchors.dat to test error during initialization":
(https://github.com/bitcoin/bitcoin/pull/26314#issuecomment-1525122282)
lgtm ACK 33fdfc7986455191df8ce339261bc0561115cf7f
💬 laanwj commented on pull request "Add support for RNDR/RNDRRS for AArch64 on Linux":
(https://github.com/bitcoin/bitcoin/pull/26839#discussion_r1178811690)
this seems correct: according to the spec "If the instruction cannot return a genuine random number in a reasonable period of time, PSTATE.NZCV is set to 0b0100 and the data value returned is 0.", so the `Z` flag is set. The `ok` flag is set to 1 (with instruction [cset](https://developer.arm.com/documentation/ddi0596/2021-12/Base-Instructions/CSET--Conditional-Set--an-alias-of-CSINC-?lang=en#sa_cond_1)) when condition `ne` holds, which means `Z==0` [conditions](https://community.arm.com/arm-com
...
💬 laanwj commented on pull request "Add support for RNDR/RNDRRS for AArch64 on Linux":
(https://github.com/bitcoin/bitcoin/pull/26839#discussion_r1178812574)
same nit as above
💬 laanwj commented on pull request "Add support for RNDR/RNDRRS for AArch64 on Linux":
(https://github.com/bitcoin/bitcoin/pull/26839#issuecomment-1525147489)
> It's not possible to directly query for the capability in userspace, but the Linux kernel [added support](https://github.com/torvalds/linux/commit/1a50ec0b3b2e9a83f1b1245ea37a853aac2f741c) for querying the extension via getauxval in version 5.6 (in 2020), so this is limited to Linux-only for now.

That's the correct way to do it. We might actually want to define `WCAP2_RNG` ourselves instead of checking for its existence, to reduce dependency on compiling with specific kernel version headers
...
💬 pinheadmz commented on pull request "blockstorage: do not flush block to disk if it is already there":
(https://github.com/bitcoin/bitcoin/pull/27039#issuecomment-1525160464)
> Maybe rebase to make CI less sad?

rebased. cheer up little guy!
💬 kristapsk commented on pull request "Add support for RNDR/RNDRRS for AArch64 on Linux":
(https://github.com/bitcoin/bitcoin/pull/26839#issuecomment-1525178903)
Concept ACK
📝 fanquake locked a pull request: "build file"
(https://github.com/bitcoin/bitcoin/pull/27536)
<!--
*** 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
...