💬 TheCharlatan commented on pull request "contrib: Update clang-format-diff":
(https://github.com/bitcoin/bitcoin/pull/29251#issuecomment-1895501411)
Updated 008e81e025d64c33e1e71b5a2fe63dfdf6b31437 -> 52149b7a2c2b48ed4a4c0900c74cda4bb52a1ea5 ([ClangFormatDiffBinaryOption_1](https://github.com/TheCharlatan/bitcoin/tree/ClangFormatDiffBinaryOption_1) -> [ClangFormatDiffBinaryOption_2](https://github.com/TheCharlatan/bitcoin/tree/ClangFormatDiffBinaryOption_2), [compare](https://github.com/TheCharlatan/bitcoin/compare/ClangFormatDiffBinaryOption_1..ClangFormatDiffBinaryOption_2))
* Added a commit fixing the lint errors by removing a python
...
(https://github.com/bitcoin/bitcoin/pull/29251#issuecomment-1895501411)
Updated 008e81e025d64c33e1e71b5a2fe63dfdf6b31437 -> 52149b7a2c2b48ed4a4c0900c74cda4bb52a1ea5 ([ClangFormatDiffBinaryOption_1](https://github.com/TheCharlatan/bitcoin/tree/ClangFormatDiffBinaryOption_1) -> [ClangFormatDiffBinaryOption_2](https://github.com/TheCharlatan/bitcoin/tree/ClangFormatDiffBinaryOption_2), [compare](https://github.com/TheCharlatan/bitcoin/compare/ClangFormatDiffBinaryOption_1..ClangFormatDiffBinaryOption_2))
* Added a commit fixing the lint errors by removing a python
...
💬 Sjors commented on pull request "build: depends move macOS C(XX) FLAGS out of C & CXX":
(https://github.com/bitcoin/bitcoin/pull/29233#issuecomment-1895512452)
Guix build on Ubuntu AMD:
```
94d2fe95101baf9ba74e5c1be6a93708bd55b3700567c768e72ceb4af4951bb9 guix-build-cbc9bf11fe84/output/aarch64-linux-gnu/SHA256SUMS.part
3cacc8c3d726e78b1db8ea07c25186e589f32c991cd7fd45d4390135adf199f2 guix-build-cbc9bf11fe84/output/aarch64-linux-gnu/bitcoin-cbc9bf11fe84-aarch64-linux-gnu-debug.tar.gz
39f42920ea452ea67f0f8df3199c50d73660009368fccfab900204d27b8e50cc guix-build-cbc9bf11fe84/output/aarch64-linux-gnu/bitcoin-cbc9bf11fe84-aarch64-linux-gnu.tar.gz
dc1a
...
(https://github.com/bitcoin/bitcoin/pull/29233#issuecomment-1895512452)
Guix build on Ubuntu AMD:
```
94d2fe95101baf9ba74e5c1be6a93708bd55b3700567c768e72ceb4af4951bb9 guix-build-cbc9bf11fe84/output/aarch64-linux-gnu/SHA256SUMS.part
3cacc8c3d726e78b1db8ea07c25186e589f32c991cd7fd45d4390135adf199f2 guix-build-cbc9bf11fe84/output/aarch64-linux-gnu/bitcoin-cbc9bf11fe84-aarch64-linux-gnu-debug.tar.gz
39f42920ea452ea67f0f8df3199c50d73660009368fccfab900204d27b8e50cc guix-build-cbc9bf11fe84/output/aarch64-linux-gnu/bitcoin-cbc9bf11fe84-aarch64-linux-gnu.tar.gz
dc1a
...
💬 willcl-ark commented on issue "./bitcoin.conf file should not cause confusion with ./datadir/bitcoin.conf":
(https://github.com/bitcoin/bitcoin/issues/29139#issuecomment-1895518581)
Perhaps the best solution is simply to move the example conf back inside `share/examples/bitcoin.conf` in the release tar, as we have it here in the repo? That way if people unzip-to-dir which I assume is how it's usually done?, the example conf also won't be floating loosely inside `/usr/local`:
```bash
# Check contents
tar -tzvf bitcoin-26.0-x86_64-linux-gnu.tar.gz
# Unzip directly to /usr/local
sudo tar -xzvf bitcoin-26.0-x86_64-linux-gnu.tar.gz -C /usr/local/
```
IMO folks looking
...
(https://github.com/bitcoin/bitcoin/issues/29139#issuecomment-1895518581)
Perhaps the best solution is simply to move the example conf back inside `share/examples/bitcoin.conf` in the release tar, as we have it here in the repo? That way if people unzip-to-dir which I assume is how it's usually done?, the example conf also won't be floating loosely inside `/usr/local`:
```bash
# Check contents
tar -tzvf bitcoin-26.0-x86_64-linux-gnu.tar.gz
# Unzip directly to /usr/local
sudo tar -xzvf bitcoin-26.0-x86_64-linux-gnu.tar.gz -C /usr/local/
```
IMO folks looking
...
💬 glozow commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1895531724)
+1 @dev7ba there's not much to go on without logs. Maybe open another report with more information if it happens again?
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1895531724)
+1 @dev7ba there's not much to go on without logs. Maybe open another report with more information if it happens again?
🚀 fanquake merged a pull request: "build: depends move macOS C(XX) FLAGS out of C & CXX"
(https://github.com/bitcoin/bitcoin/pull/29233)
(https://github.com/bitcoin/bitcoin/pull/29233)
✅ willcl-ark closed an issue: "Failed loading mempool when restarting bitcoind"
(https://github.com/bitcoin/bitcoin/issues/29193)
(https://github.com/bitcoin/bitcoin/issues/29193)
💬 willcl-ark commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1895555239)
OK let's close for now then.
@dev7ba feel free to ping me in here, or open a new issue if this happens again or you have new information.
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1895555239)
OK let's close for now then.
@dev7ba feel free to ping me in here, or open a new issue if this happens again or you have new information.
📝 Sjors opened a pull request: "Support self hosted Github workers on forks"
(https://github.com/bitcoin/bitcoin/pull/29259)
I find myself making pull requests against my fork (mostly on top of #28983), or asking others to do so. Since I don't want to splurge on a Cirrus account, and since Github free minutes are limited, I looked into how self hosted runners work on Github.
You can see this PR in action on this pull request to my fork: https://github.com/Sjors/bitcoin/actions/runs/7554260507
To test it yourself, spin up one or more [self hosted runners](https://docs.github.com/en/actions/hosting-your-own-runner
...
(https://github.com/bitcoin/bitcoin/pull/29259)
I find myself making pull requests against my fork (mostly on top of #28983), or asking others to do so. Since I don't want to splurge on a Cirrus account, and since Github free minutes are limited, I looked into how self hosted runners work on Github.
You can see this PR in action on this pull request to my fork: https://github.com/Sjors/bitcoin/actions/runs/7554260507
To test it yourself, spin up one or more [self hosted runners](https://docs.github.com/en/actions/hosting-your-own-runner
...
💬 glozow commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895559493)
Please rebase. See contributing guidelines https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895559493)
Please rebase. See contributing guidelines https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes.
💬 fanquake commented on issue "ci: failure in `wallet_basic.py --descriptors`":
(https://github.com/bitcoin/bitcoin/issues/29110#issuecomment-1895578477)
https://cirrus-ci.com/task/6509037848625152?logs=ci#L2502
(https://github.com/bitcoin/bitcoin/issues/29110#issuecomment-1895578477)
https://cirrus-ci.com/task/6509037848625152?logs=ci#L2502
💬 Retropex commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895579012)
> Please rebase.
Rebased.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895579012)
> Please rebase.
Rebased.
💬 moonsettler commented on pull request "set `DEFAULT_PERMIT_BAREMULTISIG` to false":
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895601881)
> Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.
what do we mean by ravaging? afaik the biggest unnecessary bloater of the UTXO set is the stacks protocol.
(https://github.com/bitcoin/bitcoin/pull/28217#issuecomment-1895601881)
> Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.
what do we mean by ravaging? afaik the biggest unnecessary bloater of the UTXO set is the stacks protocol.
💬 maflcko commented on pull request "Support self hosted Github workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29259#issuecomment-1895608079)
> splurge on a Cirrus account, and since Github free minutes are limited
A Cirrus account is free for public open source projects, as well as persistent workers connected to it. GitHub "free" minutes should also be unlimited for public open source, no?
> Related: I wrote a [gist](https://gist.github.com/Sjors/cd55370fa67aa095df90c433ee9bd135) for how to run CI on Ubuntu desktop with one runner per window.
Nice, but generally I don't think there is a need to run *all* CI tasks locally, b
...
(https://github.com/bitcoin/bitcoin/pull/29259#issuecomment-1895608079)
> splurge on a Cirrus account, and since Github free minutes are limited
A Cirrus account is free for public open source projects, as well as persistent workers connected to it. GitHub "free" minutes should also be unlimited for public open source, no?
> Related: I wrote a [gist](https://gist.github.com/Sjors/cd55370fa67aa095df90c433ee9bd135) for how to run CI on Ubuntu desktop with one runner per window.
Nice, but generally I don't think there is a need to run *all* CI tasks locally, b
...
💬 maflcko commented on pull request "Support self hosted Github workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29259#discussion_r1455306117)
unrelated: Generally I'd find it better if we get rid of the commit range completely. For example, when running the whitespace linter, it seems easier to just lint all code at `HEAD`, instead of trying to guess which code was modified and only lint that.
(https://github.com/bitcoin/bitcoin/pull/29259#discussion_r1455306117)
unrelated: Generally I'd find it better if we get rid of the commit range completely. For example, when running the whitespace linter, it seems easier to just lint all code at `HEAD`, instead of trying to guess which code was modified and only lint that.
💬 maflcko commented on pull request "Support self hosted Github workers on forks":
(https://github.com/bitcoin/bitcoin/pull/29259#discussion_r1455306954)
May be good to explain this change?
(https://github.com/bitcoin/bitcoin/pull/29259#discussion_r1455306954)
May be good to explain this change?
💬 maflcko commented on pull request "test: Add test case for spending bare multisig":
(https://github.com/bitcoin/bitcoin/pull/29120#issuecomment-1895628355)
Could also update the documentation of the setting to clarify that it refers to the relay of transactions which create bare outputs, and not to the relay of transactions spending them?
(https://github.com/bitcoin/bitcoin/pull/29120#issuecomment-1895628355)
Could also update the documentation of the setting to clarify that it refers to the relay of transactions which create bare outputs, and not to the relay of transactions spending them?
👍 maflcko approved a pull request: "contrib: Update clang-format-diff"
(https://github.com/bitcoin/bitcoin/pull/29251#pullrequestreview-1827105090)
lgtm ACK 52149b7a2c2b48ed4a4c0900c74cda4bb52a1ea5 🌱
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: lgtm ACK 52149b7a2c2b48e
...
(https://github.com/bitcoin/bitcoin/pull/29251#pullrequestreview-1827105090)
lgtm ACK 52149b7a2c2b48ed4a4c0900c74cda4bb52a1ea5 🌱
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: lgtm ACK 52149b7a2c2b48e
...
💬 kristapsk commented on pull request "log: Don't use scientific notation in "Dumped mempool" message":
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1895653539)
> I don't think nanosecond precision helps here. Might as well limit to `%.2fs`?
Agree, such precision is not needed, but didn't seem too important, message itself is relatively small anyway, so few extra characters doesn't hurt.
I would prefer millisecond precision, but plain `%.3f` will output 0.000 for 0.0009, don't think that's the right thing to do, should ceil or round before output then.
>
> Same here?
>
> ```
> src/policy/fees.cpp: LogPrint(BCLog::ESTIMATEFEE, "Recorded
...
(https://github.com/bitcoin/bitcoin/pull/29254#issuecomment-1895653539)
> I don't think nanosecond precision helps here. Might as well limit to `%.2fs`?
Agree, such precision is not needed, but didn't seem too important, message itself is relatively small anyway, so few extra characters doesn't hurt.
I would prefer millisecond precision, but plain `%.3f` will output 0.000 for 0.0009, don't think that's the right thing to do, should ceil or round before output then.
>
> Same here?
>
> ```
> src/policy/fees.cpp: LogPrint(BCLog::ESTIMATEFEE, "Recorded
...
🤔 furszy reviewed a pull request: "net: introduce block tracker to retry to download blocks after failure"
(https://github.com/bitcoin/bitcoin/pull/27837#pullrequestreview-1827136018)
Focus is on #28170, which is quite close.
Will rebase it as soon as it is merged.
(https://github.com/bitcoin/bitcoin/pull/27837#pullrequestreview-1827136018)
Focus is on #28170, which is quite close.
Will rebase it as soon as it is merged.
💬 tromp commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1895678731)
No matter what new restrictions are imposed, it's safe to assume that the economic reality of people wanting to inscribe data on the blockchain will persist and use whatever means is available and cheapest. There will always be means available such as spreading the data over multiple outputs or multiple txs, encoding the data as arbitrary taproot scripts, or encoding the data as fake public keys or key hashes. Some of these encodings will be detectable while others will not.
Raising the cost of
...
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1895678731)
No matter what new restrictions are imposed, it's safe to assume that the economic reality of people wanting to inscribe data on the blockchain will persist and use whatever means is available and cheapest. There will always be means available such as spreading the data over multiple outputs or multiple txs, encoding the data as arbitrary taproot scripts, or encoding the data as fake public keys or key hashes. Some of these encodings will be detectable while others will not.
Raising the cost of
...