Thoughts on burner addresses

[j2002ba2]

160 bit hash in addresses provides enough security, and that's the important part.

Right now it does. But not eventually. Quantum computer can reduce that to 80 bits.

Quantum computers cannot reduce anything. Quantum computers are just a scam hidden behind weird probabilistic equations, which are very conveniently excluding almost all real life noise. Quantum computers are so weak, that cannot factor a 6-bit number using the almighty Shor's algorithm - which "breaks ECDLP" - the number 35 turned out just too big for reliable factorization.

[larry_vw_1955]

And where did I ever say that? Quantum computers could solve certain types of problems because algorithms are known for those certain types of problems.

Exactly. They can solve "certain types of problems" but they can't magically decrease the 128-bit security of a EC private key to 80 bit.

I didn't say they could do that. What I said is they can reduce the security of a hash function in half. From 160 bits down to 80 bits.

The point is to say cryptography is not going to be broken as easily as you think otherwise we wouldn't have built so much on top of it. Historically this has also been true. We can always foresee the technical developments including hardware capabilities that could lead to weakening a cryptography algorithm and we have always been replacing them with stronger ones for the past thousand+ years.

Well I don't know all what's gone on in the past 1000+ years with regards to that but I'd say the quantum computer threat is kind of a new paradigm.

The key will still provide 128-bits of security.

If all you know is my bitcoin address, say it is a 256-bit hash. Then to attack it you could do no better than brute force search to find a pre-image. So my security is 256 bits for that. Keep in mind too that there are about 2^256 bitcoin private keys.

And if that ever becomes the case, then bitcoin will move to quantum resistant signatures.

You make it sound so simple like flipping a switch and it's all taken care of. They don't even know what signature scheme they would use.

Relying on then insecure hash functions and keeping your public keys secret is not a tenable solution.

A 256-bit hash function such as Sha-256 is secure against quantum computer pre-image attacks. 128 bits secure. Which by your own admission is good enough security.

Keeping your public key secret means never spending your coins.

No it doesn't. It just means you only use your bitcoin address one time. After that you use another one you never used before. Because once you use it the first time, the public key becomes a permanent record on the blockchain. At that point, you don't want to have funds in it anymore. it's just part of an overall security protocol for best practice.

As I said above, if your security relies on your public key being secret, then your security is broken.

It's not that it relies on it but given the choice, I prefer not to let anyone know my public key or keys. I feel more secure that way. Luckily bitcoin allows that by simply not re-using the same address more than once. I might have other security protocols too which are designed to make me feel more secure against someone cracking my private key. Such as not storing my bitcoin on an android app, etc.

Long before this becomes an issue, bitcoin will fork to quantum resistant signatures.

I think there's logistical issues in doing something like that though. Are you just going to fork bitcoin? And the old legacy chain dies off? What happens to Satoshi's bitcoin?

If you think that 128 bits of security is insecure, then you should probably stop using bitcoin. Even if you believe that all your coins are protected by 256 bits of security, the many millions of bitcoin present in addresses with exposed public keys is enough to completely crash the price of bitcoin to zero if they were suddenly all stolen and everyone lost confidence in bitcoin's security.

I think 128 bits of security is on the fence. I'd like to see higher. But it is what it is. The only way to get higher security is to change curves or change how you use the curve secp256k1. if a bitcoin public key had 256 bits of security then I wouldn't have such an issue with my public key being known.
but as it is now, i think it wise to not use a bitcoin address more than once. if i'm going to use bitcoin.

Quantum computers cannot reduce anything. Quantum computers are just a scam hidden behind weird probabilistic equations, which are very conveniently excluding almost all real life noise. Quantum computers are so weak, that cannot factor a 6-bit number using the almighty Shor's algorithm - which "breaks ECDLP" - the number 35 turned out just too big for reliable factorization

Quantum Computers do not equal Shor's algorithm. I'm pretty sure if they really wanted to they could factor something bigger than 35 though. We're way past that.

[o_e_l_e_o]

You make it sound so simple like flipping a switch and it's all taken care of. They don't even know what signature scheme they would use.

Why would we? A credible threat from quantum computing is decades away. Why would we discuss and settle on a quantum resistant algorithm now, knowing that when it comes to actually be necessary the algorithm we chose today will almost certainly be long outdated and replaced by something stronger, quicker, more efficient, etc?

No it doesn't. It just means you only use your bitcoin address one time.

And as soon you broadcast a transaction from that address, then your public key is exposed, allowing a malicious miner with a quantum computer to steal your coins. So again, if your security relies on keeping your public key private, then your security is broken.

It's not that it relies on it but given the choice, I prefer not to let anyone know my public key or keys. I feel more secure that way. Luckily bitcoin allows that by simply not re-using the same address more than once.

That's absolutely fine if that's what you want to do, and everyone should be avoiding address re-use anyway from a privacy point of view. But it is not a viable solution against quantum attacks.

I think there's logistical issues in doing something like that though. Are you just going to fork bitcoin? And the old legacy chain dies off? What happens to Satoshi's bitcoin?

The old chain doesn't die, we simply introduce a new quantum resistant address type. We've introduced many new address types over the course of bitcoin's history, such as segwit and now taproot, with no effect on previous blocks.

I think 128 bits of security is on the fence.

At 200 exahash, it would take the entire bitcoin network about 54 billion years to perform 2¹²⁸ hashes. And that's just simple hashes using highly efficient ASICs. Worth mentioning that if you think 128 bits is insecure, not only should you stop using bitcoin as I said above, but you probably need to stop using banks or even the internet and just keep all your money in cash under your mattress.

[death_wish]

Dear heavens.  I opened this thread with the intent of sending a merit to the first person to provide the correct information.  Although some mentioned OP_RETURN before that, nobody properly explained its significance before page 2.

There is only one correct way to burn bitcoins:  OP_RETURN.

Please, stop permanently and irreparably bloating the UTXO set with coins that are stuck in limbo!  You are hurting Bitcoin.  So-called “burner” addresses are misnamed.  They do not burn the coins:  They trap the coins.  They should be called “trap addresses”.  Placing sats in the amount field of an OP_RETURN output actually burns them.

The consensus rules for OP_RETURN were designed that way for a reason.  Use the consensus rules for their intended purpose.

Also, to add to what PN7 said:  There are some people out there who like to audit the Bitcoin supply.  Coins removed from the Bitcoin supply via OP_RETURN are accounted properly in those audits:  They no longer exist.

Due to coins burnt in OP_RETURN (plus at least one anomalous coinbase that destroyed coins, IIRC), the BTC max supply is less than the theoretical maximum of 20,999,999.97690000 BTC.  (It never was exactly 21 million BTC.)  Every time someone puts money in an OP_RETURN output, the maximum supply is reduced.  To find the exact numbers for the current existing supply and the current maximum supply, search for a supply audit—or do one yourself.

I would also point out that sending to a "burner" address will increase the size of the UTXO set, while an op return transaction will not. So sending to a "burner" address will make it more expensive for everyone to run a full node.

OP_RETURN transactions are really the most appropriate way to "burn" any coin that you "need" to be burned.

There is no reason to reinvent the wheel. It is already possible to burn coin via OP_RETURN transactions.

[o_e_l_e_o]

(plus at least one anomalous coinbase that destroyed coins, IIRC)

There have been quite a few, actually. I'll quote a previous post of mine:

There were many such blocks. A few larger examples:

Block 501726 claimed zero of the allowed 12.5 BTC.
Block 526591 claimed 6.25 of the allowed 12.5 BTC.
Block 164246 failed to claim any of the 1.76 BTC in fees.

Also note that block 91842 has a coinbase transaction which is identical to block 91812, and block 91880 has a coinbase transaction which is identical to block 91722. Since these transactions are identical, with identical hashes, they can only be spent once, meaning in each case 50 BTC was lost. (This bug was fixed in BIP 30.)

Also, the genesis coinbase transaction isn't part of the UTXO set, and so will not be counted by gettxoutsetinfo. The same applies to OP_RETURN outputs.

As noted, all these coins are provably and irretrievably lost. They can be permanently removed from the maximum supply.

To find the exact numbers for the current existing supply and the current maximum supply, search for a supply audit—or do one yourself.

For anyone interested (at time of writing):

Theoretical maximum supply:
(210,000 * 50) + (210,000 * 25) + (210,000 * 12.5) + ((739,692-629,999) * 6.25) = 19,060,581.25 BTC

Actual supply taken from my node using gettxoutsetinfo as of block 739,692 = 19,060,367.17900217 BTC

Discrepancy = 214.07099783 BTC

[death_wish]

(plus at least one anomalous coinbase that destroyed coins, IIRC)

There have been quite a few, actually. I'll quote a previous post of mine:

Links below cite a few more.

To find the exact numbers for the current existing supply and the current maximum supply, search for a supply audit—or do one yourself.

For anyone interested (at time of writing):

Theoretical maximum supply:
(210,000 * 50) + (210,000 * 25) + (210,000 * 12.5) + ((739,692-629,999) * 6.25) = 19,060,581.25 BTC

Actual supply taken from my node using gettxoutsetinfo as of block 739,692 = 19,060,367.17900217 BTC

Discrepancy = 214.07099783 BTC

https://blog.okcoin.com/btc-developer-asks-where-are-the-coins/
(from developer who worked on adding the gettxoutsetinfo RPC.)

https://bitcoin.stackexchange.com/questions/38994/will-there-be-21-million-bitcoins-eventually/38998#38998
(sipa, linked by above.)

Earlier thread (you’ve merited this before; not sure if it got linked here yet):
https://bitcointalk.org/index.php?topic=675321.0

Useful:
https://bitcoin-supply.com/

An audit:
https://www.pierrerochard.com/auditing-bitcoin-supply/

[o_e_l_e_o]

Earlier thread (you’ve merited this before; not sure if it got linked here yet):
https://bitcointalk.org/index.php?topic=675321.0

Useful:
https://bitcoin-supply.com/

The 2,609 BTC listed at the top of that first link, and included in the "Permanently Lost" total of the second link, is the same that I discussed earlier in this thread here: https://bitcointalk.org/index.php?topic=5400954.msg60285429#msg60285429 and https://bitcointalk.org/index.php?topic=5400954.msg60286180#msg60286180

A bit of an outlier, since these coins are not removed from the supply as with OP_RETURN outputs, but are still provably unspendable as they cannot be unlocked. If you want to add these 2,609.36304319 to the discrepancy I reach above, then the new value becomes 2,823.43404102 BTC.

[PrimeNumber7]

And don't use the same address more than once which they obviously have FAILED to do thus leaking their public key to the whole world.

Where are you referring to? The BitcoinEater address? If so, it hasn't revealed its public key, since it's a burning address. You reveal your public key when you spend one of the outputs.

I would point out that in order to know the public key, you either need to have access to the private key, or have learned information from someone who has access to the private key. The "bitcoinEater" address is claimed to be an address for which no one has the associated private key. If this is true, there is no projected risk that the private key will be able to be calculated based on the address. If it is not true, whoever has the private key can just steal the coin.

Obviously, it is difficult to know with certainty if the "bitcoinEater" address is really one for which no one knows the private key.

[BlackHatCoiner]

Obviously, it is difficult to know with certainty if the "bitcoinEater" address is really one for which no one knows the private key.

It's impossible to know with certainty, but you can easily be certain there's no such owner. Same as with PoW. You can't know with certainty that one spent millions of dollars to find a valid hash, but you can easily assume it's true, and you'll be right. One ought to spend millions, on average, to accomplish that.

It's realistically impossible to find a valid Proof-of-Work without the work.

[PrimeNumber7]

Obviously, it is difficult to know with certainty if the "bitcoinEater" address is really one for which no one knows the private key.

It's impossible to know with certainty, but you can easily be certain there's no such owner. Same as with PoW. You can't know with certainty that one spent millions of dollars to find a valid hash, but you can easily assume it's true, and you'll be right. One ought to spend millions, on average, to accomplish that.

It's realistically impossible to find a valid Proof-of-Work without the work.

Trying to brute force that address for all intents and purposes is not going to work. If you say that someone is trying to brute force that specific address, I would respond that they will be unsuccessful.

The risk to someone knowing the private key associated with the "bitcoinEater" address is that someone could have happened to have generated the private key associated with that address, saw its potential use, and published the address for people to "burn" coin to.

[BlackHatCoiner]

If you say that someone is trying to brute force that specific address, I would respond that they will be unsuccessful.

No, I was referring to why and how sure you should be there's no such owner.

[o_e_l_e_o]

Same as with PoW. You can't know with certainty that one spent millions of dollars to find a valid hash, but you can easily assume it's true, and you'll be right. One ought to spend millions, on average, to accomplish that.

It's realistically impossible to find a valid Proof-of-Work without the work.

I understand the point you are making, but your analogy isn't a great one. Occasionally someone does find a block without doing the work, as we see when an empty block is mined within a few seconds of the preceding block. The amount of work done to find such a block is only a very small fraction of the average amount of work done across all blocks at a similar difficulty. So sometimes you do find a valid solution without doing (much of) the work.

Further, sometimes you'll see a miner with the hash power of just a single ASIC finding a block. Multiple such examples here: https://bitcoinmagazine.com/markets/third-solo-bitcoin-miner-finds-valid-block. So sometimes you do find a valid solution without spending millions of dollars.

The chance of these things happening is small, but not zero. The chance of someone knowing the private key to 1BitcoinEaterAddressDontSendf59kuE is exponentially smaller, but is still not zero.

[BlackHatCoiner]

[...]

The proof that there's work remains, though. Maybe taking a block as an example is a bad analogy, because one might mine easier than another sometimes, but the difficulty is a humanly insusceptible parameter that reveals with quite certainty that there's work.

From a quick -getinfo, it's 29897409688833.63. You can't fake that, nor can you drop it by 90%* by any chance, due to the abrupt exposure of average accuracy. There's a specific work devoted, that's publicly known, miners who thrive to finding a valid hash, ASICs in limited supply. The ability for someone who "has not worked for it" to get such vanity address, AKA PoW, is very small, but less than the ability to reward themselves more than it currently has, especially at the time it firstly received coins.

Chances aren't 0%, but it's 100% pointless.

*Yes, you can't either way drop it that much, due to limit adjustment step, but point being made.

[larry_vw_1955]

I think there's logistical issues in doing something like that though. Are you just going to fork bitcoin? And the old legacy chain dies off? What happens to Satoshi's bitcoin?

The old chain doesn't die, we simply introduce a new quantum resistant address type. We've introduced many new address types over the course of bitcoin's history, such as segwit and now taproot, with no effect on previous blocks.

So you don't care what happens to peoples' bitcoin who choose not to move to this new address type? I don't think that's a reasonable solution to require people to send their bitcoin to a new address type to avoid losing their funds. That's not the same as segwit or taproot as people had a choice and the default action (none) did not have an adverse affect on them. You didn't answer the question either.
 

[j2002ba2]

Quantum computers cannot reduce anything. Quantum computers are just a scam hidden behind weird probabilistic equations, which are very conveniently excluding almost all real life noise. Quantum computers are so weak, that cannot factor a 6-bit number using the almighty Shor's algorithm - which "breaks ECDLP" - the number 35 turned out just too big for reliable factorization

Quantum Computers do not equal Shor's algorithm. I'm pretty sure if they really wanted to they could factor something bigger than 35 though. We're way past that.

Please show me anything quantum, that could factor big numbers (or even small); besides the obvious random search (adiabatic, annealing, etc), which doesn't scale, and is in fact faster on classical computers.

Who is this "we"? All I see is random buzzwords and utter failure. They wanted to factor, and failed miserably. Now there are 127 qbit computers. And they cannot factor 6 bit numbers.

Repeating buzzwords doesn't make it truth.

[o_e_l_e_o]

So you don't care what happens to peoples' bitcoin who choose not to move to this new address type? I don't think that's a reasonable solution to require people to send their bitcoin to a new address type to avoid losing their funds. That's not the same as segwit or taproot as people had a choice and the default action (none) did not have an adverse affect on them. You didn't answer the question either.

Well, that's a completely separate debate. 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.

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.

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

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

[vjudeu]

I am in favor of the latter option.

Me too. Also because that option can be turned easier to the first one, than the other way around. If coins will be stolen, then it will be possible to burn them. But if they will be burned, it will be quite hard to recreate them. I think we could just let that situation resolve itself. If someone will grab all coins, then miners could reject to mine that, or they could mine it for themselves. Some miners could decide to burn all of such coins, and then other people could follow that chain.

So, moving those coins by using OP_RETURN or destroying them inside the coinbase transaction, by sending them as a fee, may be better than artificially blacklisting them. Burning coins by breaking the private key, would be no-fork solution. Locking them somehow without owning the key, would be a soft-fork. And in case of such soft-fork, there will always be a question: is it censorship? And is it needed?

[BlackHatCoiner]

But if they will be burned, it will be quite hard to recreate them.

But, if they get burned, it doesn't make sense to recreate them later. They are either removed from circulation or not.

If someone will grab all coins, then miners could reject to mine that, or they could mine it for themselves.

I'm highly against this. If miners start rejecting transactions they don't like, despite according to their fee rate, we would no longer have censorship resistance. Furthermore, bringing these old coins into circulation, again, would either increase the supply or make them double-spent. In either case, it'd only be bad for bitcoin.

[PrimeNumber7]

If you say that someone is trying to brute force that specific address, I would respond that they will be unsuccessful.

No, I was referring to why and how sure you should be there's no such owner.

I am just as sure that the BitcoinEater address has no owner as I am that every other address that has never sent any transactions has no owner. There is nothing special about the BitcoinEater address that makes it any less likely to have an owner.

[death_wish]

Just tossing this out here:

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

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

In theory, this could be done without revealing the seed, using a zero-knowledge proof:  In theory, any operation that can be performed by a computer can have its correct performance proved in zero knowledge.  In practice, I think that running BIP39 (replete with 2048 iterations of PBKDF2-HMAC-SHA512!) and BIP32 inside an arithmetic circuit would be obscenely expensive.  Zero-knowledge proof coins go to great lengths to design protocols that are efficient inside a ZK arithmetic circuit—sometimes even inventing their own cryptographic primitives.  SHA2 functions are bad mojo here.  

In an emergency, for a one-time movement of vulnerable coins, perhaps it may be feasible even to do some expensive operations.

Furthermore, zero-knowledge proofs would allow secure spending of coins from some keypool keys, etc.  It seems impossible to provide any help there:  If the public key has been exposed, then the only secret information can be deduced by an attacker with a large quantum computer.  But if the public key has never been revealed, then you can reduce this to the security of the hash.  Anything that can be reduced to the security of a hash smells good!

Perhaps Greg Maxwell’s later-regretted meme about the safety of not revealing public keys may have some merit, after all.  Racing a quantum attacker to spend your coins is a bad idea, when you need to reveal the public key to spend your coins.  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.]

Caveat:  I had the idea for how to do this about three seconds ago.  The idea may be broken or infeasible.

And in all of the above, I won’t go beyond handwaving.  We would anyway need to see what the future state of the art is in post-quantum ZK proof systems.  Current systems are a mixed bag.  zk-SNARKs seem to have some limited resistance to some quantum computing attacks, but are probably not useful here; zk-STARKs are fully post-quantum.  This is a hot research area, and the state of the art has advanced very rapidly in the past 9 years.  IMO, as of 2022, zk-SNARKs have only just reached maturity for the current generation of deployed use cases.  Given that PQ crypto is itself a hot research area, I would expect that researchers should be interested in advancing the state of the art for PQ ZK proofs.

On a related note, I have some clever ideas for how at least a little bit of PQ crypto could be kludged into Bitcoin right now—to let people efficiently record in the blockchain a PQ way to claim their coins in this type of scenario.  (There are obviously some inefficient ways to spam the blockchain for this; don’t do it!)  Will not yet discuss:  I usually try to break the security of my own oh-so-clever ideas, before I foist them on others.  If more people did that, there would be less noise on this forum.

Yesterday, I began to write a reply to some of the other above posts re the titular topic of “burner addresses”, i.e. trap addresses.  I need to learn to write terser, less detailed technical posts.

Edit:  While I was mulling and writing the above, PN7 said in two sentences what took me twenty pages:

I am just as sure that the BitcoinEater address has no owner as I am that every other address that has never sent any transactions has no owner. There is nothing special about the BitcoinEater address that makes it any less likely to have an owner.

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?”

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.