💬 fanquake commented on issue "ci: single Windows cache takes up > 25% of total cache space":
(https://github.com/bitcoin/bitcoin/issues/33305#issuecomment-3253902831)
This was modifed, but only for master (#32182), so the cache entries are still generated from any release branch, and bloat the global cache. Apparently this may be non-trivial to backport, so can just be left as-is, for now.
(https://github.com/bitcoin/bitcoin/issues/33305#issuecomment-3253902831)
This was modifed, but only for master (#32182), so the cache entries are still generated from any release branch, and bloat the global cache. Apparently this may be non-trivial to backport, so can just be left as-is, for now.
💬 purpleKarrot commented on pull request "cmake: Inherit WERROR setting for secp256k1 build":
(https://github.com/bitcoin/bitcoin/pull/33297#issuecomment-3253905515)
> Here is some historical context.
Don't take it personal. You did a great job migrating from autotools to CMake. I have zero doubts about that.
(https://github.com/bitcoin/bitcoin/pull/33297#issuecomment-3253905515)
> Here is some historical context.
Don't take it personal. You did a great job migrating from autotools to CMake. I have zero doubts about that.
💬 wrapperband commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3253925320)
Please do not excessively increase op_return size. The coder will be as responsible for miss use as tornado cash developer - and they ended up in prison.
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3253925320)
Please do not excessively increase op_return size. The coder will be as responsible for miss use as tornado cash developer - and they ended up in prison.
💬 maflcko commented on pull request "ci: Checkout latest merged pulls":
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3253938081)
> documented
thx, added to description
> In my opinion, the current behavior is useful for reproducing issues in the CI.
If there is a hypothetical issue to reproduce by re-running, which is no longer present with current master, it seems best to reproduce with an exact commit outside this repo. (Also, I can't really remember a single instance where this was ever needed)
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3253938081)
> documented
thx, added to description
> In my opinion, the current behavior is useful for reproducing issues in the CI.
If there is a hypothetical issue to reproduce by re-running, which is no longer present with current master, it seems best to reproduce with an exact commit outside this repo. (Also, I can't really remember a single instance where this was ever needed)
🤔 rkrux reviewed a pull request: "doc: update multisig tutorial to use multipath descriptors"
(https://github.com/bitcoin/bitcoin/pull/33286#pullrequestreview-3185548980)
Concept ACK 226836e70501abf9ac2434900e74eec31edd716e
As mentioned in this comment https://github.com/bitcoin/bitcoin/pull/33286#issuecomment-3248584420 as well, I think all these commits can be squashed into one.
(https://github.com/bitcoin/bitcoin/pull/33286#pullrequestreview-3185548980)
Concept ACK 226836e70501abf9ac2434900e74eec31edd716e
As mentioned in this comment https://github.com/bitcoin/bitcoin/pull/33286#issuecomment-3248584420 as well, I think all these commits can be squashed into one.
💬 rkrux commented on pull request "doc: update multisig tutorial to use multipath descriptors":
(https://github.com/bitcoin/bitcoin/pull/33286#discussion_r2322332266)
In cf2986684ba0db4e0f7b32deb65d7767f80e9c01 "Update multisig-tutorial.md to use multipath descriptors"
Can consider moving this note in the previous section where the multipath descriptor is actually sed-ed.
```diff
diff --git a/doc/multisig-tutorial.md b/doc/multisig-tutorial.md
index fa6366df91..c59359de0a 100644
--- a/doc/multisig-tutorial.md
+++ b/doc/multisig-tutorial.md
@@ -63,6 +63,8 @@ for x in "${!xpubs[@]}"; do printf "[%s]=%s\n" "$x" "${xpubs[$x]}" ; done
As previously m
...
(https://github.com/bitcoin/bitcoin/pull/33286#discussion_r2322332266)
In cf2986684ba0db4e0f7b32deb65d7767f80e9c01 "Update multisig-tutorial.md to use multipath descriptors"
Can consider moving this note in the previous section where the multipath descriptor is actually sed-ed.
```diff
diff --git a/doc/multisig-tutorial.md b/doc/multisig-tutorial.md
index fa6366df91..c59359de0a 100644
--- a/doc/multisig-tutorial.md
+++ b/doc/multisig-tutorial.md
@@ -63,6 +63,8 @@ for x in "${!xpubs[@]}"; do printf "[%s]=%s\n" "$x" "${xpubs[$x]}" ; done
As previously m
...
⚠️ wrapperband opened an issue: "Developers will end up in prison. do not excessively increase op_return size"
(https://github.com/bitcoin/bitcoin/issues/33307)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo
- [x] I still think this issue should be opened here
### Report
Please do not excessively increase op_return size. The coder will be as responsible for miss use as shown with tornado cash developer - and they ended up in prison.
(https://github.com/bitcoin/bitcoin/issues/33307)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo
- [x] I still think this issue should be opened here
### Report
Please do not excessively increase op_return size. The coder will be as responsible for miss use as shown with tornado cash developer - and they ended up in prison.
💬 hebasto commented on pull request "ci: Checkout latest merged pulls":
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3253949621)
While testing this PR, I noticed that GitHub’s behaviour seems unreliable.
In my personal repo, I opened a PR, then pushed a commit to the default branch. After that, I checked it out with:
```
git fetch origin pull/4/merge
git rev-parse FETCH_HEAD
```
The output still refers to the branch based on the previous state of the default branch.
It took GitHub a few minutes to update the references.
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3253949621)
While testing this PR, I noticed that GitHub’s behaviour seems unreliable.
In my personal repo, I opened a PR, then pushed a commit to the default branch. After that, I checked it out with:
```
git fetch origin pull/4/merge
git rev-parse FETCH_HEAD
```
The output still refers to the branch based on the previous state of the default branch.
It took GitHub a few minutes to update the references.
✅ pinheadmz closed an issue: "Developers will end up in prison. do not excessively increase op_return size"
(https://github.com/bitcoin/bitcoin/issues/33307)
(https://github.com/bitcoin/bitcoin/issues/33307)
💬 pinheadmz commented on issue "Developers will end up in prison. do not excessively increase op_return size":
(https://github.com/bitcoin/bitcoin/issues/33307#issuecomment-3253951961)
This is a duplicate issue.
(https://github.com/bitcoin/bitcoin/issues/33307#issuecomment-3253951961)
This is a duplicate issue.
💬 wrapperband commented on issue "Developers will end up in prison. do not excessively increase op_return size":
(https://github.com/bitcoin/bitcoin/issues/33307#issuecomment-3253956541)
which issue is it a duplicate of pinheadmz ?
(https://github.com/bitcoin/bitcoin/issues/33307#issuecomment-3253956541)
which issue is it a duplicate of pinheadmz ?
💬 maflcko commented on pull request "ci: Checkout latest merged pulls":
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3253973715)
> It took GitHub a few minutes to update the references.
Correct. See https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests for the docs
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3253973715)
> It took GitHub a few minutes to update the references.
Correct. See https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests for the docs
💬 fanquake commented on pull request "build: suggest -DENABLE_IPC=OFF when missing capnp":
(https://github.com/bitcoin/bitcoin/pull/33290#discussion_r2322369577)
NACK to adding any depends specific code. `CMAKE_TOOLCHAIN_FILE` also doesn't necessarily mean a depends build; anyone can bring/use a toolchain file.
(https://github.com/bitcoin/bitcoin/pull/33290#discussion_r2322369577)
NACK to adding any depends specific code. `CMAKE_TOOLCHAIN_FILE` also doesn't necessarily mean a depends build; anyone can bring/use a toolchain file.
👍 TheCharlatan approved a pull request: "depends: strip when installing qt binaries"
(https://github.com/bitcoin/bitcoin/pull/33304#pullrequestreview-3185602637)
ACK c9d5f211c119268d776af282dfd1e8b7590aaf56
(https://github.com/bitcoin/bitcoin/pull/33304#pullrequestreview-3185602637)
ACK c9d5f211c119268d776af282dfd1e8b7590aaf56
💬 pinheadmz commented on issue "Developers will end up in prison. do not excessively increase op_return size":
(https://github.com/bitcoin/bitcoin/issues/33307#issuecomment-3253983897)
This is a duplicate of issues #33298 and #33240 Not to mention extensive discussion in pull requests #32381 #32359 and the meta discussion https://github.com/bitcoin-core/meta/discussions/18 and also the [mailing list post](https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/mJyek28lDAAJ).
In addition please keep in mind the Bitcoin Core issue tracker is used for bug reports and feature requests for this software implementation. Please see https://github.com/bitcoin-core/meta for moderation
...
(https://github.com/bitcoin/bitcoin/issues/33307#issuecomment-3253983897)
This is a duplicate of issues #33298 and #33240 Not to mention extensive discussion in pull requests #32381 #32359 and the meta discussion https://github.com/bitcoin-core/meta/discussions/18 and also the [mailing list post](https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/mJyek28lDAAJ).
In addition please keep in mind the Bitcoin Core issue tracker is used for bug reports and feature requests for this software implementation. Please see https://github.com/bitcoin-core/meta for moderation
...
⚠️ fanquake opened an issue: "GUI (?): Copying output from console causes large mem usage/OOM"
(https://github.com/bitcoin-core/gui/issues/887)
Moved from https://github.com/bitcoin/bitcoin/issues/33285.
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
Running the GUI on mainnet, I open the console, run:
`getblocktemplate '{"rules": ["segwit"]}'`
everything acts normally until then. If I then try to copy the test, memory usage blows out:
on release build, jumps from <2GB to >7GB memory
on debug build, it jumps to dozens of GB, often causing OOM and kills the process.
###
...
(https://github.com/bitcoin-core/gui/issues/887)
Moved from https://github.com/bitcoin/bitcoin/issues/33285.
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
Running the GUI on mainnet, I open the console, run:
`getblocktemplate '{"rules": ["segwit"]}'`
everything acts normally until then. If I then try to copy the test, memory usage blows out:
on release build, jumps from <2GB to >7GB memory
on debug build, it jumps to dozens of GB, often causing OOM and kills the process.
###
...
✅ fanquake closed an issue: "GUI (?): Copying output from console causes large mem usage/OOM"
(https://github.com/bitcoin/bitcoin/issues/33285)
(https://github.com/bitcoin/bitcoin/issues/33285)
💬 fanquake commented on issue "GUI (?): Copying output from console causes large mem usage/OOM":
(https://github.com/bitcoin/bitcoin/issues/33285#issuecomment-3253986988)
Moved to https://github.com/bitcoin-core/gui/issues/887.
(https://github.com/bitcoin/bitcoin/issues/33285#issuecomment-3253986988)
Moved to https://github.com/bitcoin-core/gui/issues/887.
💬 darosior commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3254037664)
I'd like to point out this concern was already addressed at length [here](https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697#p-5007-data-stored-in-an-op_return-output-doesnt-need-to-be-chunked-like-it-does-in-an-inscription-this-presents-a-risk-for-node-runners-as-it-allows-anyone-to-store-unobfuscated-data-on-their-disk-22), [here](https://gnusha.org/pi/bitcoindev/aBUlEOBqqrO
...
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3254037664)
I'd like to point out this concern was already addressed at length [here](https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697#p-5007-data-stored-in-an-op_return-output-doesnt-need-to-be-chunked-like-it-does-in-an-inscription-this-presents-a-risk-for-node-runners-as-it-allows-anyone-to-store-unobfuscated-data-on-their-disk-22), [here](https://gnusha.org/pi/bitcoindev/aBUlEOBqqrO
...
👍 hebasto approved a pull request: "ci: Checkout latest merged pulls"
(https://github.com/bitcoin/bitcoin/pull/33303#pullrequestreview-3185655446)
ACK fa8f944eaa1955e4e2c376ce36f1b1cbb1897769, tested in my personal repo.
At some point, it might be useful to use YAML anchor and aliases for repeated "Checkout" steps. For example: https://github.com/bitcoin-core/secp256k1/pull/1719/commits/50e73c6eee8be094ec75920b5b71cdc5984452de.
The new re-run behaviour will only be available for PRs that are rebased after this one is merged.
(https://github.com/bitcoin/bitcoin/pull/33303#pullrequestreview-3185655446)
ACK fa8f944eaa1955e4e2c376ce36f1b1cbb1897769, tested in my personal repo.
At some point, it might be useful to use YAML anchor and aliases for repeated "Checkout" steps. For example: https://github.com/bitcoin-core/secp256k1/pull/1719/commits/50e73c6eee8be094ec75920b5b71cdc5984452de.
The new re-run behaviour will only be available for PRs that are rebased after this one is merged.