💬 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"

💬 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
...

👍 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";

...

💬 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
...

⚠️ 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 (
...

💬 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
...

⚠️ Victorcorreiaaraujo opened an issue: "Huhg"
(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
...

✅ hebasto closed an issue: "Huhg"
(https://github.com/bitcoin-core/gui/issues/714)

:lock: hebasto locked an issue: "."
(https://github.com/bitcoin-core/gui/issues/714)

⚠️ Victorcorreiaaraujo opened an issue: "Huuu"
(https://github.com/bitcoin/bitcoin/issues/27167)
bitcoin:bc1q6tux33tev8lpwsydyvjzkrdndqpp49zvh07vaa

✅ hebasto closed an issue: "Huuu"
(https://github.com/bitcoin/bitcoin/issues/27167)

:lock: hebasto locked an issue: "."
(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)".

💬 theStack commented on pull request "fix: contrib: allow multi-sig binary verification":
(https://github.com/bitcoin/bitcoin/pull/23020#discussion_r1118120078)
Looks like this is currently dead code, as the condition for `if` 3 lines above wouldn't be true if the retval is 2 (`gpg_allowed_codes` is set to contains 0 and 2 on line 469).

💬 theStack commented on pull request "fix: contrib: allow multi-sig binary verification":
(https://github.com/bitcoin/bitcoin/pull/23020#discussion_r1118122339)
If we decide to drop it, the `--require-all-hosts` option should probably also be reconsidered. Not saying that it should also be dropped (we could and probably _should_ have more than one host in the future), but at least the help text has to be adapted, which currently explicitly mentions both bitcoin.org and bitcoincore.org.

💬 Ayms commented on issue "Allow several OP_RETURN in one tx and no limited size":
(https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1445421258)
You can invent whatever non standard solution you like as long as the tx is valid and then work with miners, but that's not the easy/standard way to go

What other standard alternatives to OP_RETURN uses Opentimestamps? As far as I know we have only two for now as standard: taproot IF but 2tx, taproot annex 1tx (not available right now), that's the other mechanisms you are refering to?

Opentimestamps looks to be working the very same way for some parts than what I am proposing for NFTs, but
...

⚠️ joyqvq opened an issue: "Error opening bitcoin core app: Error: Prune mode is incompatible with -txindex."
(https://github.com/bitcoin-core/gui/issues/715)
I downloaded bitcoin core had synced my node last week. I quit the bitcoin core and reopens, the app shows this error:

```Error: Prune mode is incompatible with -txindex.```

<img width="488" alt="image" src="https://user-images.githubusercontent.com/108701016/221428605-611c9a8d-63e8-45f6-9661-c72b6eb72cba.png">

When I click OK, the app quits. I am using:

Chip: Apple M1 Max
macOS: 13.1 (22C65)

💬 pinheadmz commented on issue "Error opening bitcoin core app: Error: Prune mode is incompatible with -txindex.":
(https://github.com/bitcoin-core/gui/issues/715#issuecomment-1445425832)
Did you change any settings or write a bitcoin.conf at any point ?

💬 joyqvq commented on issue "Error opening bitcoin core app: Error: Prune mode is incompatible with -txindex.":
(https://github.com/bitcoin-core/gui/issues/715#issuecomment-1445427145)
yes you are right! i changed it to `txindex=1`... removing it works. thanks for the help!

✅ joyqvq closed an issue: "Error opening bitcoin core app: Error: Prune mode is incompatible with -txindex."
(https://github.com/bitcoin-core/gui/issues/715)