Bitcoin Core Github
44 subscribers
121K links
Download Telegram
📝 fanquake locked a pull request: "Rename CONTRIBUTING.md to CONTRIBUTING.cryptocurrency.md"
(https://github.com/bitcoin/bitcoin/pull/30021)
<!--
*** 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
...
💬 dominicusadinfinitum commented on issue "Testsuite for Bitcoin Core 27.0.0 - FAIL: qt/test/test_bitcoin-qt":
(https://github.com/bitcoin/bitcoin/issues/30020#issuecomment-2090247040)
> @dominicusadinfinitum
>
> What are the first few lines (before "Script verification uses...") in the `debug.log` file when you run `bitcoin-qt -regtest`?

I'm new to this. Trying to figure out how to do that. Keep you updated.
💬 dominicusadinfinitum commented on issue "Testsuite for Bitcoin Core 27.0.0 - FAIL: qt/test/test_bitcoin-qt":
(https://github.com/bitcoin/bitcoin/issues/30020#issuecomment-2090271815)
> > A few other thoughts:
> >
> > 1. Have you installed all the [GUI dependencies](https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#linux-distribution-specific-instructions)? (preumably you must have, and I see "Using QtTest library 5.15.8, Qt 5.15.8", but just thought I'd double check)
> > 2. Does this happen if you configure with debug mode enabled: `./configure --enable-debug`? If so, the output may also be more useful to us to find what is failing rather than guessing fro
...
💬 hebasto commented on pull request "refactor, fuzz: Make 64-bit shift explicit":
(https://github.com/bitcoin/bitcoin/pull/30017#discussion_r1587487300)
It causes no issues?
📝 fanquake opened a pull request: "releases: use LLVM 18 for macOS"
(https://github.com/bitcoin/bitcoin/pull/30022)
Bumps the Guix time-machine to include a bump to LLVM 18.1.4: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=837016fe33e11c6252ec24c423d1b6ae0cd7efd3. Can split this out given it effects all releases.

Needs another patch to Qt. It's internal libpng build is broken with the newer Clang, due to:
> A new Clang extension (see [here](https://releases.llvm.org/18.1.0/tools/clang/docs/ReleaseNotes.html?1=#target-os-detail)) is enabled for Darwin (Apple platform) targets. Clang now defines TA
...
💬 alfonsoromanz commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1587494035)
Actually `SNAPSHOT_BASE_HEIGHT` is 299, and here I am trying to make sure that the snapshot was deleted and therefore the node is now using it's previous chain which has less work. I changed it to `assert node.getblockcount() < SNAPSHOT_BASE_HEIGHT` for more clarity
💬 alfonsoromanz commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1587496652)
Yes, good catch. This line was removed since the iteration is no longer needed based on your other comment below.
💬 alfonsoromanz commented on pull request "test: Assumeutxo: import snapshot in a node with a divergent chain":
(https://github.com/bitcoin/bitcoin/pull/29996#discussion_r1587497230)
That's a good one. Thanks. I Fixed it.
💬 paplorinc commented on pull request "refactor, fuzz: Make 64-bit shift explicit":
(https://github.com/bitcoin/bitcoin/pull/30017#discussion_r1587506138)
I don't have MSVC to test, just seemed suspicious. If it was deliberate, please resolve this comment.
💬 hebasto commented on pull request "refactor, fuzz: Make 64-bit shift explicit":
(https://github.com/bitcoin/bitcoin/pull/30017#discussion_r1587527245)
> I don't have MSVC to test, just seemed suspicious.

Do you mind elaborating your concerns?

> If it was deliberate, please resolve this comment.

The MSVC warning C4334 is caused by the type of the left-hand side operand in the `<<` operator. This PR is focused on resolving only this issue. I can't see reasons to introduce unrelated code modifications.
laanwj closed an issue: "Objdump can't parse our Linux debug information"
(https://github.com/bitcoin/bitcoin/issues/30016)
💬 dergoegge commented on pull request "releases: use LLVM 18 for macOS":
(https://github.com/bitcoin/bitcoin/pull/30022#discussion_r1587550128)
this download link works but ubuntu-18?
🤔 Sjors reviewed a pull request: "[PoC, nomerge] IPv6 PCP pinhole test"
(https://github.com/bitcoin/bitcoin/pull/30005#pullrequestreview-2035221223)
Concept ACK. RFC 6887 is quite readable and simple for a client to support.

IPv6 always returns multiple addresses. I'm not sure what the logic behind that is, but should we gossiping and pinholing all of them? Or is one "supposed" to be used?

Why not also use PCP for IPv4 NAT? If it's widely supported enough, maybe it lets us drop both upnp and natpmp from the dependencies (immediately or at some point in the future if there's actually a problem with them).

This appears to be trivial:
...
💬 Sjors commented on pull request "[PoC, nomerge] IPv6 PCP pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#discussion_r1587530201)
To make it easier to understand that 0x80 refers to R, which happens to be the most significant bit of second byte of the message, and 0x01 is the actual Opcode:

```h
// PCP Request Header. See section 7.1
constexpr uint8_t PCP_REQUEST = 0x00; // R = 0
// PCP Response Header. See section 7.2
constexpr uint8_t PCP_RESPONSE = 0x80; // R = 1
//! Map opcode. See section 19.2
constexpr uint8_t PCP_OP_MAP = 0x01;
//! Map request opcode.
constexpr uint8_t PCP_OP_MAP_REQUEST = PCP_REQUEST | P
...
💬 Sjors commented on pull request "[PoC, nomerge] IPv6 PCP pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#discussion_r1587412293)
Did you mean `pcp6: Could not connect to gateway`?
💬 Sjors commented on pull request "[PoC, nomerge] IPv6 PCP pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#discussion_r1587310888)
You could make this a permanent debugging utility by adding it to `bitcoin-util`.
💬 Sjors commented on pull request "[PoC, nomerge] IPv6 PCP pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#discussion_r1587549683)
We should explicitly set that we want this option to be mandatory (if we do indeed care that much):

> Its most significant bit indicates if this
> option is mandatory (0) or optional (1) to process.
💬 Sjors commented on pull request "[PoC, nomerge] IPv6 PCP pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#discussion_r1587540017)
In a real implementation we should log the meaning of each result code, if known.