Bitcoin Core Github
43 subscribers
122K links
Download Telegram
💬 laanwj commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#issuecomment-2068827925)
No, it isn't. Nor is piling on the `EVENT_CFLAGS`. Good catch @hebasto.
💬 virtu commented on pull request "contrib: Add asmap-tool":
(https://github.com/bitcoin/bitcoin/pull/28793#discussion_r1574349440)
```suggestion
#!/usr/bin/env python3
# Copyright (c) 2022 Pieter Wuille
```
💬 virtu commented on pull request "contrib: Add asmap-tool":
(https://github.com/bitcoin/bitcoin/pull/28793#discussion_r1574356520)
The last non-f-string left, I think.
💬 virtu commented on pull request "contrib: Add asmap-tool":
(https://github.com/bitcoin/bitcoin/pull/28793#discussion_r1574368473)
nit: I searched other scripts in `contrib` for appending to `sys.path` to find out if there's precedent one could follow:

```python
testgen/gen_key_io_test_vectors.py
14:sys.path.append(os.path.join(os.path.dirname(__file__), '../../test/functional')
message-capture/message-capture-parser.py
16:sys.path.append(os.path.join(os.path.dirname(__file__), '../../test/functional'))
```
📝 vasild opened a pull request: "doc: suggest only necessary Qt packages for installation on FreeBSD"
(https://github.com/bitcoin/bitcoin/pull/29932)
The previously suggested `qt5` package is a meta package that does not install anything itself but depends on a bunch of others and is used as a convenience to install "everything" Qt5 related: 253 packages / 3 GiB.

We only need a subset of those which amounts to 71 packages / 224 MiB, so suggest just that.

For comparison:

```
Updating local repository catalogue...
local repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The follow
...
💬 Sjors commented on pull request "rpc: Optimize serialization disk space of dumptxoutset - Reloaded":
(https://github.com/bitcoin/bitcoin/pull/29612#issuecomment-2068890350)
@fjahr sounds good. Let me know when that's ready and I'll bake a halving block snapshot...
💬 laanwj commented on pull request "doc: suggest only necessary Qt packages for installation on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/29932#issuecomment-2068899128)
Just to ask: These are stil developer packages, right, with the headers?
💬 vasild commented on pull request "doc: suggest only necessary Qt packages for installation on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/29932#issuecomment-2068914601)
Yes, in FreeBSD there is no distinction like in e.g. Debian:

```
pkg info -l qt5-network |grep ssl.h
/usr/local/include/qt5/QtNetwork/qssl.h
```

More importantly - those are the same packages that `qt5` depends on. To simplify - `qt5` depends on `qt5-foo`, `qt5-bar`, `qt5-baz`, `qt5-omg`, `qt5-whatnotonemilliondeps` whereas we only need `qt5-foo`. So, the suggestion to install `qt5` is just excessive.
💬 laanwj commented on pull request "doc: suggest only necessary Qt packages for installation on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/29932#issuecomment-2068923134)
Absolutely, it's excessive. Qt is like an operating system in itself, in depends we're also very careful to only build the parts that are needed. It makes sense to pick specific packages instead of the umbrella package.

ACK b1e98c1b36354b45c3d3ee44ec5c1d11cc9a46d2
💬 Kino1994 commented on issue "Signed Integer Overflow in GetBlockSubsidy at block height 2,147,483,647 (During Epoch 10,227, halving 10,226) could increase the block subsidy, total supply, or potentially halt the network":
(https://github.com/bitcoin/bitcoin/issues/29928#issuecomment-2068940724)
Hi @maflcko

Thank you for your feedback.

I would like to emphasize that while some bugs may seem similar or less urgent than others, it is best practice in software development to address each bug individually. This ensures that each issue is thoroughly investigated and resolved based on its own merits, rather than being bundled together or deferred due to perceived similarities. The forums you've referenced are predominantly for general Bitcoin inquiries akin to StackOverflow discussions
...
💬 BrandonOdiwuor commented on pull request "doc: explain what the wallet password does":
(https://github.com/bitcoin/bitcoin/pull/28974#discussion_r1574452288)
removed
💬 BrandonOdiwuor commented on pull request "doc: explain what the wallet password does":
(https://github.com/bitcoin/bitcoin/pull/28974#discussion_r1574452537)
fixed
💬 BrandonOdiwuor commented on pull request "doc: explain what the wallet password does":
(https://github.com/bitcoin/bitcoin/pull/28974#issuecomment-2068957042)
@fjahr I have integrated `wallet-passphrase` doc into `managing-wallets` doc. Regarding https://github.com/bitcoin/bitcoin/pull/28974#pullrequestreview-1887288612, I had created a follow up PR https://github.com/bitcoin/bitcoin/pull/29245 (which was closed)

@maflcko is https://github.com/bitcoin/bitcoin/pull/29245 close to your suggestion on https://github.com/bitcoin/bitcoin/pull/28974#issuecomment-1855661692
💬 setavenger commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2068972677)
Is there an easy way to run this pull-request version without compromising my existing full-node data and needing to resync everything? Then I could probably get to a comparison in the next days.
💬 laanwj commented on pull request "depends: Remove Qt build-time dependencies":
(https://github.com/bitcoin/bitcoin/pull/29923#issuecomment-2068994077)
Example: failure on Ubuntu 22.04:
```
$ ./bitcoin-qt
/lib/x86_64-linux-gnu/libxcb-xfixes.so.0: undefined symbol: xcb_xfixes_set_client_disconnect_mode_checked
qt.qpa.xcb: Unable to load required libraries, skipping initialization of XCB backend.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform
...
💬 maflcko commented on issue "Signed Integer Overflow in GetBlockSubsidy at block height 2,147,483,647 (During Epoch 10,227, halving 10,226) could increase the block subsidy, total supply, or potentially halt the network":
(https://github.com/bitcoin/bitcoin/issues/29928#issuecomment-2069002528)
> Addressing bugs only when they become operationally critical may not be the most prudent approach.

I did not say or imply this. I said that fixing an issue in a code base that is expected to stop working in 2106, for an issue that is expected to happen in thousands of years is useless at best. In practice, a fix now would most likely result in a increased runtime load or increased memory load, along with the risk of a consensus and chain split. Also, the C++ language is evolving rapidly ri
...
💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2069017109)
@setavenger this PR should not break your node. It just creates an `indexes/silent_payments` directory in your data dir, which you can safely delete later.
💬 Kino1994 commented on issue "Signed Integer Overflow in GetBlockSubsidy at block height 2,147,483,647 (During Epoch 10,227, halving 10,226) could increase the block subsidy, total supply, or potentially halt the network":
(https://github.com/bitcoin/bitcoin/issues/29928#issuecomment-2069021051)
So Bitcoin will cease to function in 2106 if the other issue is not fixed beforehand, making it senseless to consider this one first. Oh! Got it.

Thank you.
💬 Sjors commented on issue "CMake-based build system tracking issue":
(https://github.com/bitcoin/bitcoin/issues/28607#issuecomment-2069038272)
What's next?

It would be useful to have a link to build instructions too, not just the cheat cheat.

In noticed that in your `hebasto/cmake-staging` branch the macOS instructions still assume autotools.
💬 glozow commented on pull request "test: Fix multiprocess CI timeout in p2p_tx_download":
(https://github.com/bitcoin/bitcoin/pull/29926#discussion_r1574527033)
I haven't been able to reproduce this issue and am mostly guessing here, but if it's a `setmocktime` problem, perhaps just do a `node.setmocktime(0)` to reset it a few lines up (shouldn't impact the test except maybe make it take 2sec longer)?