Bitcoin Core Github
43 subscribers
122K links
Download Telegram
💬 marcofleon commented on pull request "fuzz: Faster utxo_snapshot fuzz target":
(https://github.com/bitcoin/bitcoin/pull/30644#issuecomment-2296780238)
ACK fa0b66400c12d11579b38b1ac76f677b23e8c82a
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1721929753)
Thanks, will do if I have to retouch.
💬 maflcko commented on pull request "fuzz: Faster utxo_snapshot fuzz target":
(https://github.com/bitcoin/bitcoin/pull/30644#issuecomment-2296824949)
Force pushed to remove stray, unused lines in the diff of the last commit. Should be easy to re-review.
📝 romanz opened a pull request: "http: set TCP_NODELAY when creating HTTP server"
(https://github.com/bitcoin/bitcoin/pull/30675)
Otherwise, the default HTTP server config may result in high latency, due to Nagle's algorithm (on the server) and delayed ACK (on the client):

[1] https://www.extrahop.com/blog/tcp-nodelay-nagle-quickack-best-practices
[2] https://eklitzke.org/the-caveats-of-tcp-nodelay


Without the fix, fetching a small block takes ~40ms (when connection keep-alive is enabled):
```
$ ab -k -c 1 -n 100 http://localhost:8332/rest/block/00000000000002b5898f7cdc80d9c84e9747bc6b9388cc989971d443f05713ee.bi
...
💬 andrewtoth commented on pull request "http: set TCP_NODELAY when creating HTTP server":
(https://github.com/bitcoin/bitcoin/pull/30675#discussion_r1721978296)
`LogPrintf` is deprecated. See https://github.com/bitcoin/bitcoin/pull/29641
💬 romanz commented on pull request "http: set TCP_NODELAY when creating HTTP server":
(https://github.com/bitcoin/bitcoin/pull/30675#issuecomment-2296860648)
`TCP_NODELAY` has been set on p2p connections by https://github.com/bitcoin/bitcoin/pull/6867.
💬 achow101 commented on pull request "seeds: Pull additional nodes from my seeder and update fixed seeds":
(https://github.com/bitcoin/bitcoin/pull/30008#issuecomment-2296871606)
> I noticed the `seeds.txt.gz` file I used (~2024-08-19T08:30Z) file did not contain any good I2P nodes.

I think it got disconnected from I2P and started marking every I2P node as down when it was actually that the crawler's I2P connection was down. That's something I'll need to fix.
⚠️ MarkLTZ opened an issue: "Unable to execute './contrib/guix/guix-build' on a fresh installed server."
(https://github.com/bitcoin/bitcoin/issues/30676)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Hello there,

executing `./contrib/guix/guix-build` I have the following error:

```
-builder for `/gnu/store/0h7r1766n7brqlvzpnb0y3vank5faizz-linux-libre-5.4.20-gnu.tar.xz.drv' failed to produce output path `/gnu/store/0zcl1i3rbjc356138hx86b7yaz29g6fj-linux-libre-5.4.20-gnu.tar.xz'
build of /gnu/store/0h7r1766n7brqlvzpnb0y3vank5faizz-linux-libre-5.4.20-gnu.tar.xz.drv failed
View bu
...
💬 pinheadmz commented on pull request "http: set TCP_NODELAY when creating HTTP server":
(https://github.com/bitcoin/bitcoin/pull/30675#issuecomment-2296950626)
concept ACK, I'm kinda surprised we don't have this already. I did a quick check into libevent and don't see any helpers there like `evutil_make_listen_socket_reuseable()` (which sets `SO_REUSEADDR` so this might be the best approach
💬 romanz commented on pull request "http: set TCP_NODELAY when creating HTTP server":
(https://github.com/bitcoin/bitcoin/pull/30675#discussion_r1722060528)
Many thanks! Fixed in f14484184f8cae134f65801647280c2c1f4930b2.
⚠️ hebasto opened an issue: "Control-flow application capabilities for `x86_64-linux-gnu` release binaries"
(https://github.com/bitcoin/bitcoin/issues/30677)
When building static binaries for `x86_64-linux-gnu`, one can verify that both Control-flow Enforcement Technology (CET) capabilities--indirect branch tracking (IBT) and shadow stack--are enabled by running the following command:
```
$ readelf -n src/bitcoind | grep feature
Properties: x86 feature: IBT, SHSTK
```
However, that is not the case for the Guix binaries:
```
$ readelf -n bin/bitcoind | grep feature
Properties: x86 feature used: x86, x87, XMM, YMM, XSAVE
```
💬 fanquake commented on issue "Control-flow application capabilities for `x86_64-linux-gnu` release binaries":
(https://github.com/bitcoin/bitcoin/issues/30677#issuecomment-2297021072)
> When building static binaries for x86_64-linux-gnu, one can verify that both ... are enabled by running the following command.

I'm guessing this is the case because your distro enables both of these by default in its compiler. You can't generally assume this.

> that is not the case for the Guix binaries:

Can you elaborate? I guess you mean the ELF .note isn't present (iirc LIEF only recently added support for checking it directly), but we have a check for atleast control flow instructions b
...
💬 theStack commented on pull request "http: set TCP_NODELAY when creating HTTP server":
(https://github.com/bitcoin/bitcoin/pull/30675#issuecomment-2297063889)
Concept ACK
💬 brunoerg commented on pull request "http: set TCP_NODELAY when creating HTTP server":
(https://github.com/bitcoin/bitcoin/pull/30675#issuecomment-2297090229)
Concept ACK
🤔 ryanofsky reviewed a pull request: "multiprocess: Add -ipcbind option to bitcoin-node"
(https://github.com/bitcoin/bitcoin/pull/30509#pullrequestreview-2245900280)
Updated 4137419b0170fa1e9ff9daacde57933f7c995b76 -> af24810eeed397c2fe5f61ef9769e1b7ee0ecdf9 ([`pr/ipc-bind.4`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-bind.4) -> [`pr/ipc-bind.5`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-bind.5), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-bind.4..pr/ipc-bind.5)) with suggested changes simplifying error handling and adding more tests.
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1722005240)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1714153255

> [a8d4adf](https://github.com/bitcoin/bitcoin/commit/a8d4adfea4b50f452d80bc1e7ee322945d886c78): @vasild's #30205 is potentially useful here. Though as long as the test is not brittle, there's no need to wait for that PR to be merged.

Agree it could be useful to test what happens when invalid data is sent or received on the socket. All the current tests are using real sockets and sending and receiving valid data.
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1722004854)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1714205805

Added a new `parse_address_test` to give this function good test coverage. I think adding a new address data type could make sense in the future if more functions use addresses, but for now only connect and listen functions use them, so adding an intermediate type now doesn't seem as simple as just passing address strings.
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1722004442)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1714091657

> [4137419](https://github.com/bitcoin/bitcoin/commit/4137419b0170fa1e9ff9daacde57933f7c995b76): I have a hard hitting this, instead I tend to get a crash (on intel macOS):

Nice catch, thanks for testing this. The error should be handled cleanly now instead of crashing. The connect and listen code was trying to make it easier to distinguish between different types of errors like connections that failed because nothing
...
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1722004255)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707536386

> Typo nit: s/if a relative paths are/if relative paths/

Thanks, fixed!