Quote from: o_e_l_e_o on Today at 07:28:46 AM

To get back on topic regarding burner addresses:

Quote from: larry_vw_1955 on Today at 02:28:05 AM

I tend to agree but the thing is nodes don't have to store OP_RETURN transactions. Those are provably unspendable so if you want to have something that is stored by every node forever then you have to store it in the utxo set.

Nodes do store OP_RETURN transactions, just as they store every transaction. What they don't do is add these unspendable outputs to their UTXO set. Any data stored using OP_RETURN outputs is still very much forever part of the blockchain.

He evidently wants to prevent pruning. That is actively malicious.

This is not about trap addresses, a.k.a. “burner addresses”. The stated goal implies a desire to store arbitrary data, and intentionally to defeat the purpose for which, after much debate, Core kept OP_RETURN with output data as a less-harmful way to store arbitrary data.

The stated goal exhibits a wanton disregard for abuse of memory and CPU resources needed by the UTXO set. (It’s not only about disk; but a blockchain spammer does not care.)

The stated goal is intentionally to force “Be Your Own Bank” Bitcoiners who run 24/7 online nodes at home on inexpensive hardware to serve as unpaid file hosts.

The stated goal is intentionally to force poor people in poor countries who are desperate for sound money to store and process oh-so-precious-snowflake graffiti on their <$50 nodes forever and forever. In the UTXO set.

This is when I start cursing.

Figure 2 at p. 7 of Sward 2018, linked above (https://doi.org/10.5195/LEDGER.2018.101).

There exist altcoins that facilitate, and even encourage the storage of arbitrary data on their blockchains. Some of them require in practice at least 256 GiB RAM (preferably 512 GiB), 32 CPU cores, terabytes of fast NVMe SSDs, and at least 1 Gbps commercial-grade Internet to run a performant node—and they still struggle to keep up with the flood of data. Go to them and pay their fees, if you want to store arbitrary data; if your data are so precious that you fancy forcing low-resource Bitcoin nodes never to prune it, then surely, you must be willing to pay for it. To be extra-helpful, I hereby offer my consultant services at a rate of $1,000/hour to anyone who needs assistance ~~spamming the hell out of~~ storing his precious-snowflake data on the Solana blockchain; my rate is subject to change without notice, as the dollar continues to inflate into utter worthlessness. There also exist file-storage blockchain projects, which may be suitable for whatever use you have in mind; expect to pay your way.

Quote from: vjudeu on Today at 04:57:50 AM

Quote from: larry_vw_1955 on Today at 02:28:05 AM

there may not even exist a public key that hashes to it

Of course. In case of hash functions, it is possible to have some hashes that are unreachable, and that no message can be hashed to that. But it is hard to prove it, without breaking such hash function.

Quote from: o_e_l_e_o on Today at 07:28:46 AM

Quote from: larry_vw_1955 on Today at 02:28:05 AM

you don't even know if the bitcoineater hash corresponds to a public key or not. there may not even exist a public key that hashes to it.

With (almost) 2²⁵⁶ possible private keys and 2¹⁶⁰ possible P2PKH addresses, then it is highly likely that there is a valid private key. But yes, impossible to prove without finding such a key. But still, this goes back to the original point: When you cannot prove one way or another whether a private key exists or whether someone knows that private key, then these coins are not provably unspendable.

There should be approximately slightly less than 2⁹⁶ valid keys per address. (Not the same number for every address, of course.) If it were significantly not so—due to “unreachable” hashes, or otherwise—then the distribution of hash images would be distinguishable from the uniform distribution; that breaks it for anything that relies on the Random Oracle Model, among other problems. I would be very interested in seeing the reasons why people believe that RIPEMD-160 is so badly broken.

As I said above, and as PrimeNumber7 noted, there is no cause for a security concern that someone may have the private key. Not if the full Hash160 has some human-language semantics, in the style of a vanity address. That is essentially a type of Nothing-Up-My-Sleeve Number. The resulting address is not “provably unspendable”—to the contrary, there are around 2⁹⁶ ways to spend it, which is why it needs to remain in the UTXO set. But we can be confident that nobody knows how to spend it. If you are worried that someone out there may have the private key, then you should also be worried that someone can find the private keys for your own addresses.

Larry has been been labouring under the mistaken belief that I need to prove to him that my idea can work. That’s not my problem.

I did make one significant error in a statement above. (Hey, if PN7 can sometimes have a “need more coffee” moment here, then so can I!) It will be corrected presently, with an appropriate note.