💬 sipa commented on issue "miniscript_stable fuzz timeout":
(https://github.com/bitcoin/bitcoin/issues/27147#issuecomment-1445211590)
See #27165.
(https://github.com/bitcoin/bitcoin/issues/27147#issuecomment-1445211590)
See #27165.
⚠️ Victorcorreiaaraujo opened an issue: "Any report, issue or feature request related to the GUI should be reported at "
(https://github.com/bitcoin-core/gui/issues/713)
Any report, issue or feature request related to the GUI should be reported at
https://github.com/bitcoin-core/gui/issues/
(https://github.com/bitcoin-core/gui/issues/713)
Any report, issue or feature request related to the GUI should be reported at
https://github.com/bitcoin-core/gui/issues/
✅ hebasto closed an issue: "Any report, issue or feature request related to the GUI should be reported at "
(https://github.com/bitcoin-core/gui/issues/713)
(https://github.com/bitcoin-core/gui/issues/713)
:lock: hebasto locked an issue: "."
(https://github.com/bitcoin-core/gui/issues/713)
(https://github.com/bitcoin-core/gui/issues/713)
💬 MarcoFalke commented on pull request "25574 followups (VerifyDB error handling)":
(https://github.com/bitcoin/bitcoin/pull/27157#issuecomment-1445319780)
It might be good to explain and motivate the behaviour change. Calling it "25574 followups" is less useful than, for example, mentioning if the exit code is changed, if a warning will be printed, or if this turns an operation into an error?
(https://github.com/bitcoin/bitcoin/pull/27157#issuecomment-1445319780)
It might be good to explain and motivate the behaviour change. Calling it "25574 followups" is less useful than, for example, mentioning if the exit code is changed, if a warning will be printed, or if this turns an operation into an error?
💬 hebasto commented on issue "build: multiprocess link issues on fedora aarch64":
(https://github.com/bitcoin/bitcoin/issues/26943#issuecomment-1445324025)
> The decoded symbol name is `kj::_::Debug::minSeverity` which is a symbol in the `libkj.a` library
If we expect that the static `libkj.a` library is used rather than the shared `libkj.so` one, maybe it makes sense to configure with `--disable-shared` for all platforms, not just for Android?
(https://github.com/bitcoin/bitcoin/issues/26943#issuecomment-1445324025)
> The decoded symbol name is `kj::_::Debug::minSeverity` which is a symbol in the `libkj.a` library
If we expect that the static `libkj.a` library is used rather than the shared `libkj.so` one, maybe it makes sense to configure with `--disable-shared` for all platforms, not just for Android?
💬 Ayms commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445336629)
Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned"
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445336629)
Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned"
💬 petertodd commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445349756)
The fact that Core devs feel like they can close this with no explanation at all suggests that protocols should use the backup mechanism of polluting the UTXO set. The dust limit is low enough that for a lot of use cases a few extra outputs isn't a big deal.
On February 26, 2023 12:29:49 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
>Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned"
>
>--
>Reply to this email dire
...
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445349756)
The fact that Core devs feel like they can close this with no explanation at all suggests that protocols should use the backup mechanism of polluting the UTXO set. The dust limit is low enough that for a lot of use cases a few extra outputs isn't a big deal.
On February 26, 2023 12:29:49 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
>Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned"
>
>--
>Reply to this email dire
...
👍 theStack approved a pull request: "prune: scan and unlink already pruned block files on startup"
(https://github.com/bitcoin/bitcoin/pull/26533)
Code-review ACK 3141eab9c669488a2e7fef5f60d356ac92294922
FWIW, was curious how calling `fs::remove` on thousands of non-existing files would affect the performance (on mainnet, there is currently >3400 .blk/.rev files). But as expected, it's not a big deal:
```
$ cat remove_test.cpp
#include <filesystem>
#include <string>
int main() {
for (int i = 0; i < 10000; ++i) {
std::string filename = "/home/thestack/" + std::to_string(i) + ".dat";
...
(https://github.com/bitcoin/bitcoin/pull/26533)
Code-review ACK 3141eab9c669488a2e7fef5f60d356ac92294922
FWIW, was curious how calling `fs::remove` on thousands of non-existing files would affect the performance (on mainnet, there is currently >3400 .blk/.rev files). But as expected, it's not a big deal:
```
$ cat remove_test.cpp
#include <filesystem>
#include <string>
int main() {
for (int i = 0; i < 10000; ++i) {
std::string filename = "/home/thestack/" + std::to_string(i) + ".dat";
...
💬 1440000bytes commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445378974)
> The fact that Core devs feel like they can close this with no explanation at all suggests that protocols should use the backup mechanism of polluting the UTXO set. The dust limit is low enough that for a lot of use cases a few extra outputs isn't a big deal.
> […](#)
> On February 26, 2023 12:29:49 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote: Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned" -- Reply to this em
...
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445378974)
> The fact that Core devs feel like they can close this with no explanation at all suggests that protocols should use the backup mechanism of polluting the UTXO set. The dust limit is low enough that for a lot of use cases a few extra outputs isn't a big deal.
> […](#)
> On February 26, 2023 12:29:49 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote: Why do you close it "as not planned"? Of course a modification request is "not planned", or who decided that it is "not planned" -- Reply to this em
...
⚠️ glozow reopened an issue: "Allow several OP_RETURN in one tx and no limited size"
(https://github.com/bitcoin/bitcoin/issues/27043)
The rationale is explained in this thread [[bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021435.html)
And other threads around that are addressing about the same subject: bring NFTs or other systems on or off chain and easy storage to Bitcoin
As mentionned in the thread there are so many possibilities to store things in Bitcoin, including very deviant practices like storing in addresses (
...
(https://github.com/bitcoin/bitcoin/issues/27043)
The rationale is explained in this thread [[bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021435.html)
And other threads around that are addressing about the same subject: bring NFTs or other systems on or off chain and easy storage to Bitcoin
As mentionned in the thread there are so many possibilities to store things in Bitcoin, including very deviant practices like storing in addresses (
...
💬 Ayms commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445386715)
@petertodd If I understand correctly your comment, you mean that without this change (as I think too) people will invent stupid things like I am myself proposing here (ie storing in addresses, with uncompressed keys, worse method on earth, but not expensive as you say and as I wrote, let's say that we will survive it and don't care for the future) : https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation, then indeed polluting the UTXO set with no
...
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445386715)
@petertodd If I understand correctly your comment, you mean that without this change (as I think too) people will invent stupid things like I am myself proposing here (ie storing in addresses, with uncompressed keys, worse method on earth, but not expensive as you say and as I wrote, let's say that we will survive it and don't care for the future) : https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation, then indeed polluting the UTXO set with no
...
⚠️ Victorcorreiaaraujo opened an issue: "Huhg"
(https://github.com/bitcoin-core/gui/issues/714)
bitcoincom://multisig/join/526923daa75cc2bca4ac923998752242
(https://github.com/bitcoin-core/gui/issues/714)
bitcoincom://multisig/join/526923daa75cc2bca4ac923998752242
💬 petertodd commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445400939)
On February 26, 2023 4:17:28 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
>@petertodd If I understand correctly your comment, you mean that without this change (as I think too) people will invent stupid things like I am myself proposing here (ie storing in addresses, with uncompressed keys, worse method on earth, but not expensive as you say and as I wrote, let's say that we will survive it and don't care for the future) : https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workar
...
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445400939)
On February 26, 2023 4:17:28 PM GMT+01:00, Aymeric Vitte ***@***.***> wrote:
>@petertodd If I understand correctly your comment, you mean that without this change (as I think too) people will invent stupid things like I am myself proposing here (ie storing in addresses, with uncompressed keys, worse method on earth, but not expensive as you say and as I wrote, let's say that we will survive it and don't care for the future) : https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workar
...
✅ hebasto closed an issue: "Huhg"
(https://github.com/bitcoin-core/gui/issues/714)
(https://github.com/bitcoin-core/gui/issues/714)
:lock: hebasto locked an issue: "."
(https://github.com/bitcoin-core/gui/issues/714)
(https://github.com/bitcoin-core/gui/issues/714)
⚠️ Victorcorreiaaraujo opened an issue: "Huuu"
(https://github.com/bitcoin/bitcoin/issues/27167)
bitcoin:bc1q6tux33tev8lpwsydyvjzkrdndqpp49zvh07vaa
(https://github.com/bitcoin/bitcoin/issues/27167)
bitcoin:bc1q6tux33tev8lpwsydyvjzkrdndqpp49zvh07vaa
✅ hebasto closed an issue: "Huuu"
(https://github.com/bitcoin/bitcoin/issues/27167)
(https://github.com/bitcoin/bitcoin/issues/27167)
:lock: hebasto locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/27167)
(https://github.com/bitcoin/bitcoin/issues/27167)
💬 theStack commented on pull request "fix: contrib: allow multi-sig binary verification":
(https://github.com/bitcoin/bitcoin/pull/23020#discussion_r1118115828)
```suggestion
signature check or the hash check doesn't pass. An exit code of >=2 indicates an error.
```
non-blocking nit: could list all the individual return code's meaning here, or at least mention something like "(see the `ReturnCode` class for individual error reasons)".
(https://github.com/bitcoin/bitcoin/pull/23020#discussion_r1118115828)
```suggestion
signature check or the hash check doesn't pass. An exit code of >=2 indicates an error.
```
non-blocking nit: could list all the individual return code's meaning here, or at least mention something like "(see the `ReturnCode` class for individual error reasons)".