Bitcoin Core Github
43 subscribers
122K links
Download Telegram
šŸ’¬ mzumsande commented on pull request "validation: improve performance of CheckBlockIndex":
(https://github.com/bitcoin/bitcoin/pull/28339#discussion_r1571211066)
> Any reason not to use ActiveTip() instead of m_best_header here

My main reason is that `CheckBlockIndex()` being independent from the active chainstate makes the performance improvement applicable to situations where we have all the headers but haven't validated much of the chain: See [this old answer](https://github.com/bitcoin/bitcoin/pull/28339#discussion_r1307561848). IBD and reindex seem much more relevant than extreme `invalidateblock` scenarios.
šŸ’¬ fjahr commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#discussion_r1571211295)
I also found this a bit strange but it's the behavior of libevent and they have an explicit test case for this. I didn't investigate this further yet and I think the safest option is to keep this a pure refactor for now.
šŸ’¬ stratospher commented on pull request "test: Fix intermittent issue in p2p_handshake.py":
(https://github.com/bitcoin/bitcoin/pull/29898#discussion_r1571231602)
> Another thing we could do is to not only do peer.wait_for_disconnect() but also wait until the bitcoind side has disconnected - something like self.wait_until(lambda: len(self.nodes[0].getpeerinfo()) == X). Haven't tried that though.

yeah this sounds like a better option! updated the PR to use this approach.

> (that is for the duration of all tests, not the test itself) to avoid port collisions.

oh makes sense, a TIL!
šŸ“ ryanofsky opened a pull request: "Disable util::Result copying and assignment"
(https://github.com/bitcoin/bitcoin/pull/29906)
This PR just contains the first two commits of #25665.

It disables copying of `util::Result` objects because unnecessary copies are inefficient and not possible after #25665, which makes `util::Result` object move-only.

It disables the assignment operator and replaces it with an `Update()` method, because #25665 adds more information to `util::Result` objects (warning and error messages and failure values) and having an assignment operator that overwrites data instead of merging it would m
...
šŸ“ ryanofsky converted_to_draft a pull request: "refactor: Add util::Result failure values, multiple error and warning messages"
(https://github.com/bitcoin/bitcoin/pull/25665)
**This PR is based on #29906.**

---

Add `util::Result` support for returning more error information and make use of it in [LoadChainstate method](https://github.com/bitcoin/bitcoin/pull/25665/commits/6ec8f408b81d06354277a5ee8a53c8c724e1a927) as an initial application. Followup PR [#25722](https://github.com/bitcoin/bitcoin/pull/25722) uses it more broadly to return errors and warnings from wallet loading functions as well.

This change adds two major features to the result class:

- Fo
...
šŸ’¬ ryanofsky commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#issuecomment-2065005417)
Converted to draft since first 2 commits were moved to a separate PR, #29906
šŸ’¬ fjahr commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#discussion_r1571252576)
done
šŸ’¬ fjahr commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#discussion_r1571252651)
Added a short docstring.
šŸ’¬ stickies-v commented on pull request "rpc: return warnings as an array instead of just a single one":
(https://github.com/bitcoin/bitcoin/pull/29845#discussion_r1571252879)
I've added a `-rpcdeprecated=warnings` config option and updated the release notes.
šŸ’¬ fjahr commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#issuecomment-2065027349)
Addressed @stickies-v 's feedback as well, thanks a lot!
šŸ’¬ stickies-v commented on pull request "rpc: return warnings as an array instead of just a single one":
(https://github.com/bitcoin/bitcoin/pull/29845#issuecomment-2065029694)
Force pushed to add `-deprecatedrpc=warnings` to address [review concerns](https://github.com/bitcoin/bitcoin/pull/29845#discussion_r1571053657).
šŸ’¬ laanwj commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#discussion_r1571288106)
Indentation isn't right here
šŸ’¬ fjahr commented on pull request "refactor: Use our own implementation of urlDecode":
(https://github.com/bitcoin/bitcoin/pull/29904#discussion_r1571291302)
fixed
šŸ“ hebasto opened a pull request: "test: Fix `test/streams_tests.cpp` compilation on SunOS / illumos"
(https://github.com/bitcoin/bitcoin/pull/29907)
On systems where `int8_t` is defined as `char`, the `{S,Uns}erialize(Stream&, signed char)` functions become undefined.

This PR resolves the issue by testing `{S,Uns}erialize(Stream&, int8_t)` instead.

No behavior change on systems where `int8_t` is defined as `signed char`, which is the case for most other systems.

Fixes https://github.com/bitcoin/bitcoin/issues/29884.

An alternative approach is mentioned in https://github.com/bitcoin/bitcoin/issues/29884#issuecomment-2058434577 as
...
šŸ’¬ hebasto commented on issue "`test/streams_tests.cpp` fails to compile on SunOS / illumos":
(https://github.com/bitcoin/bitcoin/issues/29884#issuecomment-2065265007)
> Happy to review a pull, if someone creates one.

Please see https://github.com/bitcoin/bitcoin/pull/29907.
šŸ’¬ fjahr commented on pull request "index: race fix, lock cs_main while 'm_synced' is subject to change":
(https://github.com/bitcoin/bitcoin/pull/29867#discussion_r1571344947)
nit: I had to read this three times to get it right, but feel free to ignore unless you have to retouch.

I would change it to `[...], so commit the data that was indexed so far.`
šŸ’¬ fjahr commented on pull request "index: race fix, lock cs_main while 'm_synced' is subject to change":
(https://github.com/bitcoin/bitcoin/pull/29867#issuecomment-2065283298)
Code review ACK 65951e0418c53cbbf30b9ee85e24ccaf729088a1
āš ļø hebasto opened an issue: "test: SegFault in `ismine_tests` on SunOS / illumos"
(https://github.com/bitcoin/bitcoin/issues/29908)
```
$ gdb -q --args ./src/test/test_bitcoin -t ismine_tests
Reading symbols from ./src/test/test_bitcoin...
(gdb) run
Starting program: /export/home/hebasto/git/bitcoin/build/src/test/test_bitcoin -t ismine_tests
[Thread debugging using libthread_db enabled]
warning: could not convert 'mutex_t' from the host encoding (ISO-8859-1) to UTF-32.
This normally should not happen, please file a bug report.
Running 1 test case...
[New Thread 1 (LWP 1)]

Thread 2 received signal SIGSEGV, Segmen
...
šŸ’¬ petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-2065525144)
On Thu, Apr 18, 2024 at 11:24:20AM -0700, Antoine Riard wrote:
> > An update to @petertodd's stats from July, at least 97.7 % of hashrate (monthly average) is now running FullRBF based on FullRBF'd transactions from within the past 24 hours.
>
> 97.7 % of hashrate is just overwhelming in matters of hashrate support for `mempoolfullrbf`. I’m still curious if anyone has data on the additional accumulated absolute fee traffic yielded by non-opting replacement that would have not propagated under l
...
āš ļø kosuodhmwa opened an issue: "~/.bitcoin (which is a softlink to a separate vmware virtual drive) dir is now almost 1tb"
(https://github.com/bitcoin/bitcoin/issues/29909)
it's happened after i
- used version 27.x (built yesterday from master branch)

but i don't no it's because of new version 27.0 or not. (?)


**bitcoin.conf file:**

proxy=127.0.0.1:9050
listen=1
bind=127.0.0.1


server = 1
rpcallowip = 127.0.0.1
rpcport = 8332
rpcuser = myuser
rpcpass = mypass
txindex = 1


i was thinking it's enough to use 1tb drive for ~/.bitcoin directory (which contains the full block chain and other things)

thank you very much for you
...