💬 murchandamus commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878746998)
Concept NACK
### Purpose of `datacarriersize`
`datacarriersize` refers to the payload of OP_RETURN outputs, the output type that was introduced as a data carrier to provide an alternative for more harmful ways of embedding data. At that time, there was a worry that any blockspace production in excess of the demand from monetary transactions would be filled for cheap since demand for highly replicated perpetual storage is unbounded. Bounding standard transactions to a single data carrier ou
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878746998)
Concept NACK
### Purpose of `datacarriersize`
`datacarriersize` refers to the payload of OP_RETURN outputs, the output type that was introduced as a data carrier to provide an alternative for more harmful ways of embedding data. At that time, there was a worry that any blockspace production in excess of the demand from monetary transactions would be filled for cheap since demand for highly replicated perpetual storage is unbounded. Bounding standard transactions to a single data carrier ou
...
💬 cliobitcoinbank commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878754502)
> > eragmus
>
> You are quite literally word for word repeating talking points made by BSV users who intend to harm Bitcoin by spamming the UTXO set and creating an unreasonably high fee environment in which the average end user is incentivised not to participate or if so forced into a custodial solution from which their Bitcoin fails to actually be a bearer instrument.
>
> https://www.youtube.com/watch?v=-RswZDQTqsI
>
> All the connections were made by a random pleb in this video, don'
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878754502)
> > eragmus
>
> You are quite literally word for word repeating talking points made by BSV users who intend to harm Bitcoin by spamming the UTXO set and creating an unreasonably high fee environment in which the average end user is incentivised not to participate or if so forced into a custodial solution from which their Bitcoin fails to actually be a bearer instrument.
>
> https://www.youtube.com/watch?v=-RswZDQTqsI
>
> All the connections were made by a random pleb in this video, don'
...
💬 cliobitcoinbank commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878760436)
> > "Bitcoin works on economic incentives"
>
> is not just some magical phrase you can throw around and make your assertions true. the incentives for full node runners are becoming smaller and smaller every single day. this demonstrably hurts decentralization of bitcoin. you people would care about that if you actually cared about the state of the mempool, but instead you are concern trolling that setting a filter to EVENLY DISTRIBUTE COST for all transactions will kill the mempool. Your fall
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878760436)
> > "Bitcoin works on economic incentives"
>
> is not just some magical phrase you can throw around and make your assertions true. the incentives for full node runners are becoming smaller and smaller every single day. this demonstrably hurts decentralization of bitcoin. you people would care about that if you actually cared about the state of the mempool, but instead you are concern trolling that setting a filter to EVENLY DISTRIBUTE COST for all transactions will kill the mempool. Your fall
...
💬 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