Thoughts on burner addresses

[larry_vw_1955]

Now there are 127 qbit computers. And they cannot factor 6 bit numbers.

And you come to that conclusion, how?

If the time comes that the ECDLP is broken by quantum computer and we can no longer rely on elliptic curve cryptography, then bitcoin will and must fork to some quantum resistant algorithm.

Better sooner than later then. The sooner the better. But they can't do it sooner you said because it needs time for research. but nist already is in their final stages. and bitcoin will probably have to go with something they crown. whether that's good or bad.

The question you are posing is how to go about doing that. Saying that you don't think it's reasonable to expect people to send their bitcoin to a new address type is missing the point - if ECDLP is broken, then all current addresses are vulnerable. We can't make ECDLP magically secure again and let people continue to use their current addresses.

Well the reason I say it's not reasonable is that not everyone is going to be able to move their bitcoins. Most people that used bitcoin in the past and probably many of them today think that their bitcoin is safe forever and there would be no need to ever change anything about it. But some people won't be alive maybe they gifted their bitcoin to some future descendents in a will or something. maybe using something like nlocktime. so all the descendent has is a (hopefully) secret transaction they can broadcast at some future time. they wont have any private key so they wont be able to "move any funds" to a new address type without first letting them to go the old address type first. now you can say that is dumb inheritance planning but maybe its the best they could do is put it in a bank deposit vault and that's it.

The only option is to introduce a new quantum resistant address type and  give everybody plenty of time to move across to it (in the order of several years).

Well, how would you prove quantum resistance? Or would you just cross your fingers and hope it was. Because if it ever got cracked them bitcoin would really be in trouble then. So whatever address type they move to they better get it right the first time is all i can say i don't think they get a second shot.

What happens with coins that don't move becomes the real issue here - do we either decide as a community to permanently lock them* so they can never be moved again, or do we just ignore them and let them be stolen by whoever manages to first and then re-enter the general circulation. I am in favor of the latter option.

well you're assuming it has to be one or the other. if someone didn't spend using the address then no one is going to crack it unless they can crack hash functions which is not realistically possible. now all they have to do is get a bitcoin mining setup and try and mine their own transactions and don't broadcast their transaction but just mine a block it is in.

*Perhaps the best option, but one which would need a lot more work to be viable, would be to lock all these coins but provide a mechanism to unlock them if the real owner can provide some quantum-resistant proof that they are indeed the real owner. An example would be if I could prove that I owned the seed phrase which generated a given wallet or address. Such a mechanism (if developed) would only solve this issue for seed phrase generated addresses though, and there are a lot of vulnerable coins in P2PK address and other non HD wallets that this does not address.

Well if you could pull something like that off, you might as well just use it as your new signature scheme to replace the broken one. No need for a new quantum resistant address. For seed phrases anyway...but why couldn't it apply to other things too? If it can work with a seed phrase why not with any other piece of information?

But a ZK proof could let you never reveal the public key!  Prove in zero knowledge that you know a private key, which produces an undisclosed public key, which has the publicly known hash.  [Edit:  Or, keep it simple.  Prove in zero knowledge that you know the preimage to the hash, and “somehow” use that to spend the coins.  A proper approach here would need to be designed carefully, and subjected to a rigorous security analysis.  —End of edit.]

that's an interesting concept but i'm not sure if it is possible. hash functions don't have any type of exploitable structure to them.

[1714496608]

1714496608

[1714496608]

1714496608

[1714496608]

1714496608

[1714496608]

1714496608

[death_wish]

Why are people arguing with a troll who is habitually derailing threads with plausible-looking nonsense?

I know that I inadvertently somehow contributed, by replying to a remark by o_e_l_e_o that caught my attention.  The brainstorm thus inspired is offtopic here; it deserves its own thread, which I should make in due course when I have time to elaborate on it a bit.

This thread is about so-called “burner addresses”, which I say should be more properly called trap addresses.

The user who is derailing threads is free to make a thread to discuss his concerns about quantum computers.  Though I’m not sure of what value that would be; the development forum has already had numerous such threads, some of which were eventually locked by the moderators due to pointless repetition.  Anyway, I will be reporting this user’s continued offtopic posts as offtopic.  This shall be my one and only offtopic reply to him here:

But a ZK proof could let you never reveal the public key!  Prove in zero knowledge that you know a private key, which produces an undisclosed public key, which has the publicly known hash.  [Edit:  Or, keep it simple.  Prove in zero knowledge that you know the preimage to the hash, and “somehow” use that to spend the coins.  A proper approach here would need to be designed carefully, and subjected to a rigorous security analysis.  —End of edit.]

that's an interesting concept but i'm not sure if it is possible. hash functions don't have any type of exploitable structure to them.

It not only possible, but nowadays quite easy to prove in zero knowledge that you know the preimage of a hash, without revealing the preimage.  Empirical evidence:  Zcash exists, and it works.  (Take a look at its “nullifier” system that prevents double-spends of shielded notes; it does something conceptually related, but much more complicated.)

You clearly have no idea what you are talking about.  With your gabble about “exploitable structure”, you are just trolling with b.s. abuse of jargon to try to make yourself sound like a cryptographer.

[PrimeNumber7]

Although hash functions should not be able to go from hash to original (they should not be able to be reversed, and they should be one way), it is not possible to know with certainty that a particular hash function is, in fact one-way. In the past, encryption algorithms that were thought to be unbreakable have been broken by cryptographers.

[vapourminer]

Although hash functions should not be able to go from hash to original (they should not be able to be reversed, and they should be one way), it is not possible to know with certainty that a particular hash function is, in fact one-way. In the past, encryption algorithms that were thought to be unbreakable have been broken by cryptographers.

maybe im misunderstanding something.

if i take one megabyte (or 8 megabits) chunk of data and hash it down to a 128 bit hash, how can that be reversed? ie there are more bits information in the original than in the hash. therefore information is irretrievably thrown away, yes?

[PrimeNumber7]

Although hash functions should not be able to go from hash to original (they should not be able to be reversed, and they should be one way), it is not possible to know with certainty that a particular hash function is, in fact one-way. In the past, encryption algorithms that were thought to be unbreakable have been broken by cryptographers.

maybe im misunderstanding something.

if i hash a one megabyte (or 8 megabits) chunk of data and hash it down to a 128 bit hash, how can that be reversed? ie there are more bits information in the original than in the hash. therefore information is irretrievably thrown away, yes?

As I noted, it should not be possible to reverse a hash function. If there was some kind of pattern in the output of the hash function, in theory, the function could be reversed.

Some hash functions also have limits as to how much data can be hashed. In theory, a hash function could be reversed in a way such that you can take the hash and calculate every potential input with a range the input having a data size of 0 through the maximum.

[death_wish]

Although hash functions should not be able to go from hash to original (they should not be able to be reversed, and they should be one way), it is not possible to know with certainty that a particular hash function is, in fact one-way. In the past, encryption algorithms that were thought to be unbreakable have been broken by cryptographers.

maybe im misunderstanding something.

if i take one megabyte (or 8 megabits) chunk of data and hash it down to a 128 bit hash, how can that be reversed? ie there are more bits information in the original than in the hash. therefore information is irretrievably thrown away, yes?

That’s the Pigeonhole Principle.  It is the same reason why it is mathematically impossible to build a lossless compressor that produces a shorter output for every input, recursively apply it to its own output, and thus, reductio ad absurdum, losslessly compress all data in the universe down to 1 bit of information.  All lossless compressors produce outputs longer than the input for some inputs; all compressors that produce a shorter output for every possible input are lossy compressors, whose outputs cannot all be decompressed with bit-for-bit identical roundtrip results.

Crackpots perennially annoy or entertain us with new designs for compressors that claim to violate the Pigeonhole Principle.  It is the information-theoretic counterpart to teaching those stupid physicists that a true genius can harvest free energy from the Earth’s rotation, or build a perpetual motion machine.  (Reviewing recent threads, I am just waiting for stereotypical crackpot SapphireSpire to invent a way to compress the blockchain with recursive lossless compression.  Not a few have tried that.)

A cryptographically secure hash function is also called a compression function.  Needless to say, it is a very lossy compressor that irretrievably discards most of the input information.

As I noted, it should not be possible to reverse a hash function. If there was some kind of pattern in the output of the hash function, in theory, the function could be reversed.

No, even CRC-32 cannot be inverted to retrieve the input.  Even CRC-8 cannot be inverted to retrieve the input.

Some hash functions also have limits as to how much data can be hashed. In theory, a hash function could be reversed in a way such that you can take the hash and calculate every potential input with a range the input having a data size of 0 through the maximum.

Even a cryptographic hash with a finite domain of preimages (inputs) will map an astronomically huge set of different preimages to each possible image (output).  Even if the hash is ridiculously broken, the image does not and cannot contain sufficient information to distinguish each possible preimage uniquely, or even to a practically useful degree of probability.  Not if your only starting information is the hash image!

It would be easier to address this, if you were to state what concrete goal you are trying to achieve.  Your post about this did not quote or reference any prior posts.  OT here, but I note as a precaution just in case if it was in reference to anything I said, or any reader may be confused to assume so:  Proving a statement in zero knowledge as I proposed does not rely in any way, shape, or form on inverting the hash.  That would be obvious to anyone who knows how modern zero-knowledge proof systems work.  (Maxwell’s description in that blog post is a good bird’s-eye overview, but it describes the state of the art in early 2016; nowadays, the trusted setup has been replaced with something trustless, and ZK proof systems now require orders of magnitude less CPU and memory.)

[larry_vw_1955]

You clearly have no idea what you are talking about.  With your gabble about “exploitable structure”, you are just trolling with b.s. abuse of jargon to try to make yourself sound like a cryptographer.

'

If you re-read what i said, I said it sounded interesting but i wasn't sure if it was possible. Hash functions dont have nice mathematical properties such as h(a+b)=h(a)+h(b). You are clearly a genius though as evidenced by your continued brilliant posts on this particular topic of zero knowledge proofs. Bitcoin is really lucky to had someone like that because they might be able to help bitcoin become quantum resistant.

[pooya87]

In theory, a hash function could be reversed in a way such that you can take the hash and calculate every potential input with a range the input having a data size of 0 through the maximum.

That is not reversing a hash, that is called finding a collision.
Theoretically and practically hash functions (both cryptographically secure and insecure algorithms) are and will always be irreversible.
To put simply if you can reverse the following function and tell me what `a` and `b` were you can also reverse hash functions:

Code:

a + b = 10

[vjudeu]

Hash functions dont have nice mathematical properties such as h(a+b)=h(a)+h(b).

You can use homomorphic encryption if you need such properties.

To put simply if you can reverse the following function and tell me what `a` and `b` were you can also reverse hash functions:

Code:

a + b = 10

Exactly. Inside hash functions, there are many things that are irreversible. If you have "uint32=mod(otherUint32+anotherUint32,2^32)", then there is no chance to reverse it, because for any given "uint32", there are 2^32 possible pairs of "(otherUint32,anotherUint32)", that will lead us to the same result. Also, there are binary operations, like AND, OR, XOR, that will mix it further, and make it a complete mess. Also don't forget about rotations, they are making it rock solid, because then tracking dependencies between single bits is getting exponentially harder. I think some explanation of the hash functions, based on reduced number of rounds, should be prepared, I will add it to my TODO list.

[death_wish]

Hash functions dont have nice mathematical properties such as h(a+b)=h(a)+h(b).

You can use homomorphic encryption if you need such properties.

Homomorphic encryption would not grant such properties to a hash—not to the hash itself—but that is irrelevant here:  Such properties are not needed.  The ignoramus who spat out that brilliant observation was making a non sequitur, like observing that hash functions are not the colour mauve.  Well, of course not.  So what?

In theory, any operation that can be performed by a computer can have its correct performance proved in zero knowledge.

To illustrate:  For publicly known Hash160 image H of secret preimage secp256k1_pubkey, you can prove in zero knowledge that you ran a program that outputs true for the following:

Code: (Pseudocode)

RIPEMD160(SHA256(secp256k1_pubkey)) == H

Verifying the proof does not require any knowledge of secp256k1_pubkey.

Neat trick, eh?  That’s the toy version; it simply proves that you know the unrevealed public key.  Building this into a system that permits secure spending of funds would necessarily be more complicated; and since the objective here is post-quantum emergency salvaging of coins, it may need to use something other than current-generation zk-SNARKs.^*

It is not merely theoretical.  Zcash has been deployed in production for almost six years, running a financial network where you prove in zero knowledge that you ran a program that validates your own transaction.  Consensus nodes then verify your proof, without knowing any information about the transaction’s inputs and outputs.  With a nod to Clarke, “Any sufficiently advanced cryptography is indistinguishable from magic.”

I have believed for years that zero-knowledge proofs will take over the world.  When time permits, I will open the new thread that I’ve been intending for days about zero-knowledge proofs, and the application thereof in Bitcoin.  (A prior impetus for that was my desire to avoid derailing another thread with discussion of using ZK proofs to build a trustless BTC wrapper/bridge.)  It will be self-moderated to cut noise.  Meanwhile, those who are curious about the topic can find a research bibliography and a little survey of implementations here:

https://zkp.science/

FHE is an entirely different topic—and another hot area of rapidly developing research.  I want to learn more about that, and especially about potential applications thereof for solving the problem that we can’t publish secrets on a public blockchain.  If you have knowledge and ideas on this subject, that would be interesting!

To put simply if you can reverse the following function and tell me what `a` and `b` were you can also reverse hash functions:

Code:

a + b = 10

Exactly. Inside hash functions, there are many things that are irreversible. If you have "uint32=mod(otherUint32+anotherUint32,2^32)", then there is no chance to reverse it, because for any given "uint32", there are 2^32 possible pairs of "(otherUint32,anotherUint32)", that will lead us to the same result. Also, there are binary operations, like AND, OR, XOR, that will mix it further, and make it a complete mess. Also don't forget about rotations, they are making it rock solid, because then tracking dependencies between single bits is getting exponentially harder. I think some explanation of the hash functions, based on reduced number of rounds, should be prepared, I will add it to my TODO list.

I suggest an inductive reductio ad absurdum:  “Hash” some data with CRC-8, which has no cryptographic security whatsoever.  Attempt to retrieve the data.  If you succeed, then you have discovered that CRC-8 is a lossless compressor that can compress large amounts of arbitrary data down to a single byte!  That’s obviously impossible.  Q.E.D.:  Hash functions cannot be inverted to retrieve their inputs.

Your thread about hash functions will also be interesting.

^* zk-STARKs are PQ crypto; they rely only on the security of a hash function, but I am not sure if they are the best option here.  There is some debate about zk-SNARKs and quantum computing attacks; I would need to learn more before opining.  Edit 2022-06-11 (original):  Duh, I conflated soundness with zero-knowledge.  AFAIK, there is no debate about whether a quantum computer that could break typical ECC could annihilate the soundness of zk-SNARKs—that is, whether it would be able to forge fake proofs.  The question, rather, is of how much privacy Zcash users would retain against retrospective decryption in a post-quantum world.  That depends on the intricacies of the Zcash protocol, not only on the properties of zk-SNARKs.  AFAIK, Zcash users will retain privacy for, and only for, funds received by addresses that have never been revealed anywhere that a quantum attacker could find it.  AFAIK (and I am not sure about this), the SNARKs themselves lack information that could be recovered by a quantum attacker; but the Zcash protocol encrypts transaction details on-chain with ordinary use of EC public-key cryptography, using a public key derived from the receiving address.  Of course, the quantum attacker could break the latter.  Anyway, STARKs it is—those are PQ crypto.

[larry_vw_1955]

Or, keep it simple.  Prove in zero knowledge that you know the preimage to the hash, and “somehow” use that to spend the coins.  A proper approach here would need to be designed carefully, and subjected to a rigorous security analysis.  —End of edit.]

Well I don't think that would work. But if you think so then maybe you can explain more about how you can just spend bitcoin by proving you know the pre-image of the hash. Using words like "somehow" doesn't help your case at all.

The reason not to use trap addresses is that they trap unspendable coins in the UTXO set.

For that reason, and only that reason, the one and only correct way to burn coins is to use OP_RETURN.

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.

It is not merely theoretical.  Zcash has been deployed in production for almost six years, running a financial network where you prove in zero knowledge that you ran a program that validates your own transaction.  Consensus nodes then verify your proof, without knowing any information about the transaction’s inputs and outputs.  

i'm still skeptical that you can do anything to make bitcoin be quantum resistant using zk snarks. and make it be efficient and make it so that i never need to share my public key all i ever need to do is share my address. if that was the case then why wouldn't bitcoin be doing that right now?

I have believed for years that zero-knowledge proofs will take over the world. When time permits, I will open the new thread that I’ve been intending for days about zero-knowledge proofs, and the application thereof in Bitcoin. It will be self-moderated to cut noise.  

i doubt such a thread is going to accomplish any meaningful objectives because you seem to have a disdain for people you deem to not know as much about the topic as you do.

Worries about the security of an address with human-language semantics that take the whole Hash160 are logically equivalent to newbie questions about “what if someone accidentally generates the same private keys as I do?”

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.

[vjudeu]

Using words like "somehow" doesn't help your case at all.

I think this word was used, because there is no BIP that you could follow step-by-step. But I know it is possible, you can try Homomorphic Encryption, and then come back with news like "Homomorphic Encryption cannot solve this, because of that". But I think you will also see, that it is possible.

so if you want to have something that is stored by every node forever then you have to store it in the utxo set

You never need to have anything that is stored always and forever, by every node. Putting data in OP_RETURN is better. Putting them as a witness is better. Not putting them on-chain and committing to them is better. There are many ways that are better (and cheaper) than trapping coins.

if that was the case then why wouldn't bitcoin be doing that right now?

Because programmers have more ideas, than they can turn into code in their lifetime. Also because people are unaware of the technical details behind some ideas. Some altcoiners could stay with Bitcoin, if they would know, how many things they could do, without creating any new coins. For example this one, Using Merged Mining on a separate zero supply chain, instead of sidechains. You know what was the first response? The first sentence was "I proposed something similar years ago". You know what does it mean? It means many people have many ideas, but they have more of them, than they are capable of turning into practical software. And there were many such cases, where someone proposed something, and received a response that "something similar was proposed before". Here is another example: Adding SIGHASH to TXID. And the first response. The first sentence was "Have you seen the inherited ID proposal from John Law on this list?". After reading more and more such examples, the conclusion is simple: people have many ideas. But having some idea and sharing that is one thing. Coding all of that is another thing, much harder, and that's why you don't have such features yet. But I think they will come, contributions are welcome, to make it real, it is needed to turn ideas into code.

because you seem to have a disdain for people you deem to not know as much about the topic as you do

I prefer talking with people that know the topic, instead of people that are polite. They don't have to use nice words. Especially when they are right, for example in case of this topic. It is derailed. It should be splitted somehow.

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.

[o_e_l_e_o]

To get back on topic regarding burner addresses:

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.

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.

[death_wish]

To get back on topic regarding burner addresses:

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.

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.

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.  Edit:  Done.  See correction to footnote in this post.

[vjudeu]

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.

I don't think it is "so badly broken". I think that some values may sometimes be unreachable, because this area is unknown, as long as some hash function is not fully broken. For example, SHA-256 returns 256-bit hash, SHA-512 returns 512-bit hash. One is just expanded version of another one. But it is possible to shrink it in the same way as it was expanded. Then, you can reach SHA-128 (16-bit) or SHA-64 (8-bit). And after running some tests, for some rounds I exhausted the search space in some cases. For example, when something is double-hashed, then (obviously) for some hashes it may turn out that there is no solution at all, just because it is not a bijection, and then if there are collisions, then there are also cases, where there is no solution.

When it comes to addresses, then they are double-hashed. First by SHA-256, and then by RIPEMD-160. I don't have a proof that all addresses are always reachable (it is very likely that they are), but I won't be surprised if some of them won't be. If you have "uint32=AND(0xbadc0ded,someOtherUint32)", then 0xffffffff is unreachable. If you have "uint32=OR(0xc0deba5e,otherUint32)", then 0x00000000 is unreachable. Inside hash functions, there is a mess. Some operations preserve bijection, but it is not always the case. Then, if you have 64 rounds in some hash function, it may be the case that for 63 rounds you will reach some value, but not for 64 rounds, because of internal operations, where dependencies between bits won't let you reach some result.

[PrimeNumber7]

In theory, a hash function could be reversed in a way such that you can take the hash and calculate every potential input with a range the input having a data size of 0 through the maximum.

That is not reversing a hash, that is called finding a collision.
Theoretically and practically hash functions (both cryptographically secure and insecure algorithms) are and will always be irreversible.
To put simply if you can reverse the following function and tell me what `a` and `b` were you can also reverse hash functions:

Code:

a + b = 10

Hash functions will typically use the modulo operator (the remainder when dividing a number by a particular another number).

A very simple hash function, that can easily be reversed might be one that only accepts integers from 0 through 100, and will output the mod 10 of the input. So the 'hash' of 11 would be 1, and the input of a 'hash' output of 1 could be any of 1, 11, 21, 31, 41, 51, 61, 71, 81, or 91.

Sometimes, businesses will use a simple hash function, similar to the above to store user-provided data, but prior to finding the modulo of the input, they will add a "salt" to the input as a means to prevent the user from being able to arbitrarily creating collisions.

The 'a' + 'b' = 10 formula is not a hash function. A hash function will always take a single input, and will produce the same output every time the same input is used.

[pooya87]

they will add a "salt" to the input as a means to prevent the user from being able to arbitrarily creating collisions.

Salt is added only to increase the difficulty of brute forcing if the database of that site was leaked.

The 'a' + 'b' = 10 formula is not a hash function. A hash function will always take a single input, and will produce the same output every time the same input is used.

I never said it is a hash function, it is one of many steps used in a hash function and if you can't reverse that, you can not reverse the hash itself!
This is the last thing that happens in SHA256 before the final hash is produced:

Code:

    h0 := h0 + a
    h1 := h1 + b
    h2 := h2 + c
    h3 := h3 + d
    h4 := h4 + e
    h5 := h5 + f
    h6 := h6 + g
    h7 := h7 + h

[larry_vw_1955]

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

ok you got me. i'm not a big fan of it, pruning that is. but maybe not for the reasons you think. i think every node should have to store all the blockchain data and here is why: i don't ever want to one day be trying to consult a blockchain explorer and it won't show me some of my old transactions because it pruned them.

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.

Yeah but it all comes down to the fact that you can't enforce anything when something is an "opt-in" mechanism. Nice people might opt in but not so nice people don't have to and probably don't care at all the affects of their actions. Their actions probably do have affects. But they don't care about them.

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

You have to design a system to be robust against people trying to abuse it. Because, and this might be a suprise to you, but they will try. Anything they can do to disrupt it and make it nonfunctional they'll try. People have different reasons for their behavior. Some just want to cause destruction, some just want to hog up resources in a greedy way. But I think we should all agree that people act in their best self interests. And do things they thnk will benefit them even at the cost to others in some cases. I'm sure some of you guys/gals here on the forum are better than that and wouldn't try and abuse some feature of bitcoin but the world at large is another story. We can't just trust people do be nice in the real world. Bitcoin is better than that. Should be better than that.

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.

That's right. I want anyone that runs a node to store the entire blockchain for me so that I can see all of my old transactions. You can call that greedy or whatever you like but to me, that's what I want.

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.

poor people in poor countries may not even have a computer. and i would think are less likely to be running nodes than people that are more financially well off. the poor people probably use an app on their phone when it comes to bitcoin. come on now.

This is when I start cursing.

Curse all you like but you only have the bitcoin developers to blame for any shortcomings of the bitcoin protocol as far as what it allows people to do.

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 (https://github.com/solana-labs/solana/issues/21604).  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.

Well we got a bit off track but burner addresses are I would assume, to your way of thinking, an abuse of the bitcoin network. And to an extent, I would agree. But again, we only have bitcoin devs to blame for allowing something to be possible if they really do frown upon it. Now where I think you go wrong though is in assuming I or anyone wants to pay to store data. I'm well aware of services like filecoin but I don't think its a very good deal. It's only temporary storage. I am not willing to pay forever to store data. So you're wrong.

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.

How about unlimited lifetime storage for $1000? Can you offer me that?

[o_e_l_e_o]

i don't ever want to one day be trying to consult a blockchain explorer and it won't show me some of my old transactions because it pruned them.

Then run your own node. No one is required to run a full node instead of a pruned node because you want them to.

Although it's probably worth pointing out that any blockchain explorer which prunes all transactions from x number of blocks ago would be useless to most users and would receive very little traffic.

the poor people probably use an app on their phone when it comes to bitcoin. come on now.

Maybe. Or maybe they actually care about the core principles of bitcoin and want to be able to verify transactions and blocks themselves and not have to trust third parties to do it for them.

[garlonicon]

Then run your own node. No one is required to run a full node instead of a pruned node because you want them to.

Exactly. There were many altcoins, where people thought that "someone" will run a full node. Guess what: in some cases nobody did, and then there were cases, when it was no longer possible to create new full nodes, because all nodes were prunned, so it was no longer possible to do initial blockchain download.

After thinking more about that, you will understand, why storing large data on-chain is not a good idea. Then you will start to think about the opposite case: data compression, and making initial blockchain download easier, to make it more decentralized, and to encourage people to maintain the network.