💬 pablomartin4btc commented on pull request "rpc,rest,zmq: faster getblock, NotifyBlock and rest_block by reading raw block":
(https://github.com/bitcoin/bitcoin/pull/26415#discussion_r1442950533)
Thought was due to #28438 & #28448... but just found #28890, nice! This PR required rebase anyways.
(https://github.com/bitcoin/bitcoin/pull/26415#discussion_r1442950533)
Thought was due to #28438 & #28448... but just found #28890, nice! This PR required rebase anyways.
💬 ajtowns commented on pull request "Change Luke Dashjr seed to dashjr-list-of-p2p-nodes-maybe-malware.us":
(https://github.com/bitcoin/bitcoin/pull/29145#issuecomment-1878797165)
> The DNS seeds resolve to IPs of random peers. It's entirely possible (and apparently reality) that some of those host malware.
It's entirely possible that one could be hosting a nascent superintelligence that's just escaped from a AI lab, but you're not adding "maybe-superintelligence" to the name. Even more likely for some of them to be chainanalysis spy nodes, or any number of other potentially worrying things.
FWIW, knots hasn't yet been updated to be malware adjacent: https://github.
...
(https://github.com/bitcoin/bitcoin/pull/29145#issuecomment-1878797165)
> The DNS seeds resolve to IPs of random peers. It's entirely possible (and apparently reality) that some of those host malware.
It's entirely possible that one could be hosting a nascent superintelligence that's just escaped from a AI lab, but you're not adding "maybe-superintelligence" to the name. Even more likely for some of them to be chainanalysis spy nodes, or any number of other potentially worrying things.
FWIW, knots hasn't yet been updated to be malware adjacent: https://github.
...
💬 pablomartin4btc commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442990315)
I agree to move it to the `CConman::AddWhitelistPermissionFlags` (since the obj has both `whitelist_forcerelay` & `whitelist_relay` vars already set) and you could have something like `CConman:UpdateNetPermissionsFlags`with the logic below.
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442990315)
I agree to move it to the `CConman::AddWhitelistPermissionFlags` (since the obj has both `whitelist_forcerelay` & `whitelist_relay` vars already set) and you could have something like `CConman:UpdateNetPermissionsFlags`with the logic below.
💬 ajtowns commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878831217)
Seems pointless to argue the politics of the change when CI doesn't even pass:
```
tests.cpp:1570:35: error: use emplace_back instead of push_back [modernize-use-emplace,-warnings-as-errors]
test/script_tests.cpp(1492): error: in "script_tests/script_DataCarrierBytes": check 13 == (CScript() << zeros(11) << OP_DROP).DatacarrierBytes() has failed [13 != 0]
```
There are two different aspects of mempool policy: what you can configure the software to enforce, and the defaults. From that
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878831217)
Seems pointless to argue the politics of the change when CI doesn't even pass:
```
tests.cpp:1570:35: error: use emplace_back instead of push_back [modernize-use-emplace,-warnings-as-errors]
test/script_tests.cpp(1492): error: in "script_tests/script_DataCarrierBytes": check 13 == (CScript() << zeros(11) << OP_DROP).DatacarrierBytes() has failed [13 != 0]
```
There are two different aspects of mempool policy: what you can configure the software to enforce, and the defaults. From that
...
📝 fanquake opened a pull request: "build: remove `--enable-lto`"
(https://github.com/bitcoin/bitcoin/pull/29185)
This has outlived its usefulness, doesn't gel well with newer compilers & `-flto` related options, i.e thin vs full, or `=auto`, and having `-flto` as the only option means that sometimes this just needs to be worked around, i.e in oss-fuzz:
https://github.com/google/oss-fuzz/blob/master/projects/bitcoin-core/build.sh.
While it was convenient when `-flto` was newer, support for `-flto` is now in all compilers we use, and there's also no-longer any real need for us to treat `-flto` different
...
(https://github.com/bitcoin/bitcoin/pull/29185)
This has outlived its usefulness, doesn't gel well with newer compilers & `-flto` related options, i.e thin vs full, or `=auto`, and having `-flto` as the only option means that sometimes this just needs to be worked around, i.e in oss-fuzz:
https://github.com/google/oss-fuzz/blob/master/projects/bitcoin-core/build.sh.
While it was convenient when `-flto` was newer, support for `-flto` is now in all compilers we use, and there's also no-longer any real need for us to treat `-flto` different
...
💬 ben-arnao commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878846817)
> > All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don't really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn't n
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878846817)
> > All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don't really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn't n
...
💬 ben-arnao commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878848506)
> > All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don't really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn't n
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878848506)
> > All these people really care about is being able to inscribe data in an immutable and decentralized manner, they don't really care about it being done on BTC blockchain in particular. I feel like if someone came along and created a solution for this purpose purely run on fees (basically a blockchain without the concept of token ownership) this would probably solve the problem IMO. Obviously there would be the issue of needing to somehow pay miners, but that part not being centralized isn't n
...
💬 maflcko commented on pull request "build: remove `--enable-lto`":
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878848718)
> ... treat -flto different to any other optimization option.
Can you explain what that means? Is the recommended way to manually override CXXFLAGS and LDFLAGS now?
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878848718)
> ... treat -flto different to any other optimization option.
Can you explain what that means? Is the recommended way to manually override CXXFLAGS and LDFLAGS now?
💬 fanquake commented on pull request "guix: use GCC 12.3.0 to build releases":
(https://github.com/bitcoin/bitcoin/pull/27897#issuecomment-1878850259)
Drafting this until (may rebase on top of) #21778, which fixes the macOS build failures by just deleting the offending code.
(https://github.com/bitcoin/bitcoin/pull/27897#issuecomment-1878850259)
Drafting this until (may rebase on top of) #21778, which fixes the macOS build failures by just deleting the offending code.
📝 fanquake converted_to_draft a pull request: "guix: use GCC 12.3.0 to build releases"
(https://github.com/bitcoin/bitcoin/pull/27897)
Switch to using [GCC `12.3.0`](https://gcc.gnu.org/gcc-12/) to build release binaries.
Update the vmov-alignment patch, for changes in GCC 12.
Guix Build:
```bash
TBD
```
(https://github.com/bitcoin/bitcoin/pull/27897)
Switch to using [GCC `12.3.0`](https://gcc.gnu.org/gcc-12/) to build release binaries.
Update the vmov-alignment patch, for changes in GCC 12.
Guix Build:
```bash
TBD
```
✅ achow101 closed a pull request: "datacarriersize: Match more datacarrying"
(https://github.com/bitcoin/bitcoin/pull/28408)
(https://github.com/bitcoin/bitcoin/pull/28408)
💬 achow101 commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878853896)
It's abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone. At this point in time, I see no reason to leave this open and to continue to send notifications for the constant back-and-forth stalemate discussion.
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878853896)
It's abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone. At this point in time, I see no reason to leave this open and to continue to send notifications for the constant back-and-forth stalemate discussion.
📝 achow101 locked a pull request: "datacarriersize: Match more datacarrying"
(https://github.com/bitcoin/bitcoin/pull/28408)
Updates `-datacarriersize` to be effective with newer datacarrying styles.
(https://github.com/bitcoin/bitcoin/pull/28408)
Updates `-datacarriersize` to be effective with newer datacarrying styles.
💬 hebasto commented on pull request "build: remove `--enable-lto`":
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878858797)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878858797)
Concept ACK.
💬 fanquake commented on pull request "build: remove `--enable-lto`":
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878861715)
> Can you explain what that means? Is the recommended way to manually override CXXFLAGS and LDFLAGS now?
Yea. `-flto` is really no different to `-O2` or any other compile option, so using it will require adding `-flto=*`, and any other related options you might want, i.e using a link cache via `-Wl,-cache_path_lto`, to the respective *FLAGS vars. Note that this is already required by anyone wanting to do anything other, or in addion to just using `-flto` with the current options (or they'd ha
...
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878861715)
> Can you explain what that means? Is the recommended way to manually override CXXFLAGS and LDFLAGS now?
Yea. `-flto` is really no different to `-O2` or any other compile option, so using it will require adding `-flto=*`, and any other related options you might want, i.e using a link cache via `-Wl,-cache_path_lto`, to the respective *FLAGS vars. Note that this is already required by anyone wanting to do anything other, or in addion to just using `-flto` with the current options (or they'd ha
...
👍 hebasto approved a pull request: "crypto: remove use of BUILD_BITCOIN_INTERNAL macro in sha256"
(https://github.com/bitcoin/bitcoin/pull/29180#pullrequestreview-1806188076)
ACK 86712c3135786b305f27c44dffd0808be0ee7170.
(https://github.com/bitcoin/bitcoin/pull/29180#pullrequestreview-1806188076)
ACK 86712c3135786b305f27c44dffd0808be0ee7170.
💬 hebasto commented on pull request "crypto: remove use of BUILD_BITCOIN_INTERNAL macro in sha256":
(https://github.com/bitcoin/bitcoin/pull/29180#discussion_r1443020894)
typo: unoptomized --> unoptimized
(https://github.com/bitcoin/bitcoin/pull/29180#discussion_r1443020894)
typo: unoptomized --> unoptimized
🚀 fanquake merged a pull request: "doc: Clarify C++20 comments"
(https://github.com/bitcoin/bitcoin/pull/29042)
(https://github.com/bitcoin/bitcoin/pull/29042)
🚀 fanquake merged a pull request: "build: remove systemtap variadic patch"
(https://github.com/bitcoin/bitcoin/pull/29181)
(https://github.com/bitcoin/bitcoin/pull/29181)
💬 maflcko commented on pull request "build: remove `--enable-lto`":
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878872129)
> to the respective *FLAGS vars
Ah, I guess this would disable O2, see https://github.com/bitcoin/bitcoin/pull/28071/files. So I guess it would have to be appended to `CXX` and possibly `LDFLAGS`.
(https://github.com/bitcoin/bitcoin/pull/29185#issuecomment-1878872129)
> to the respective *FLAGS vars
Ah, I guess this would disable O2, see https://github.com/bitcoin/bitcoin/pull/28071/files. So I guess it would have to be appended to `CXX` and possibly `LDFLAGS`.