In order to put a bitcoin beyond use, the answer was to select a made up address. As this isn't a formal destruction of bitcoins, there's a risk that the private keys could be found to spend those "destroyed" bitcoins.

If someone suggests an address, people might suspect that this address was selected because that person painstakingly looked for an address that looked like a made up address.

How can an address for bitcoin destruction be selected that everyone can be reasonably sure no-one's going to know the private keys to spend the destroyed bitcoins?

Since the address uses the pubkeyhash not the actual pubkey we can exploit this by hashing an invalid pubkey (one which can't possibly exist) and thus produce a valid address from an invalid pubkey.

So to start we find an invalid public key. All valid public keys begin with 0x04 if uncompressed and 0x02 or 0x03 if compressed. A pubkey beginning with any other value is undefined and thus there is no possible signature that can be created to satisfy that key requirement. Since spending coins requires signing the transaction with the correct private key, an address which has no known private key is unspendable. By using a public key which is known to not have a private key others can confirm that no private key exists.

There are other ways to produce a known invalid public key. ECDSA keys must be exactly 65 bytes if uncompressed or 33 bytes if compressed so a key with a different length will also be invalid. For uncompressed keys the y value must be correctly produced from the x value. The point must also lie on the curve. It also can't be above the modulus for the curve. So there are a lot of ways to produce provably invalid keys but it best to choose one which is obviously invalid. This is probably the simplest obviously invalid public key.

0x00

This public key is invalid for a number of reasons (not produced by private key multiplied by the generator, not located on the curve, not a valid point, but even simpler it doesn't have a valid prefix and is not the correct length).

The important thing is this isn't just some probably invalid key it is a provably invalid key.

You should test your invalid public key against the reference client to ensure the client reports it as invalid as well. The validity of keys is a consensus issue so this will not change short of a hard fork.

You may wonder why we want the address to be valid. All clients should validate addresses given by users to avoid accidental loss of funds. So an invalid address is also unspendable but most users will find it impossible to send funds to the address. A P2PkH address is the pubkeyhash with version and checksum information encoded in base58.

When you provide an address to a Bitcoin client it decodes the address back down to the 'raw' pubkeyhash. So producing a valid address means starting with a valid pubkeyhash. This isn't a problem because the hash of anything is a valid hash. Clients don't know what pubkey is hashed to produce the pubkeyhash as the underlying pubkey is not provided and hashing functions are one way.

The Bitcoin network only verifies that an address is in the right form, length, and has the right checksum when "validating it". Producing an address from a pubkey is beyond the scope of this question but there are utilities and the link above provides the steps. The resulting pubkeyhash and encoded address will be seen as valid by the network and client but it requires a provably impossible private key to spend funds sent to that address.

Now with just the address (and decoded pubkeyhash) a user can't verify that the underlying pubkey is invalid so you should publish the raw pubkey along with the address. Users can recreate the address using any bitcoin client or tool and will produce the same address you provide. Users now have a trustless way to verify that the coins indeed are unspendable. Any coins sent to the address can never be spent and are effectively destroyed.

Hash collision

Technically it is possible but improbable for more than one public key to have the same Bitcoin address. This is called a hash collision. If public key p1 and public key p2 both hash to the same address A then privates keys for either of these public keys can spend the funds. However the likely of this happening is very low. Unless RIPEMD hash algorithm is broken the probability of finding two public keys which generate the same hash (Bitcoin address) is 1 in 2^160 which is far beyond our computational power to locate.

A few words on why you should use a 'Nothing Up My Sleeve' number:

Using a "nothing up my sleeve number" (such as a single zero, all zeroes, single repeating digit, sequential numbers, digits of pi, etc) is not required as any invalid public key is equally unspendable but it would improve public confidence that you haven't already found a collision (as improbable as that is).

Some may question why you chose this specific key. The fear would be that you choose this key not randomly but because you have stumbled upon a collision between this key and a valid key. There is no way to prove the key is random thus the fear will always remain. Cryptographic functions (like RIPEMD or SHA-256) often use "nothing up my sleeve values" to provide security that a constant was not chosen to enable some cryptographic flaw or "backdoor" in the algorithm. For example SHA-256 uses constants for the initial values of the block segments. Technically these could be any random number but that would lead to concern that the 'random' number isn't actually random. So SHA-256 uses first 32 bits of the fraction portion of the cube root of the first 8 prime numbers. This allows verification when a pseudo random number is needed. It is very unlikely there is some magical property between the fractional portion of the cube root of sequential prime numbers that undermines SHA-256.

Update (03/31/2015)

It is easier to do this now by using an OP_RETURN (null data) output and it doesn't bloat the UTXO with outputs that can't be spent but the network is unaware they can't be spent. Any funds sent to an output which contains OP_RETURN are provably unspendable and the network will drop the output from the UTXO. The UTXO (unspent tx output set) is a critical resources which is necessary for validating new transactions and blocks so destroying/burning coins using UTXO is a more responsible use of this shared resource.

I think there is an error in the formula in your first paragraph. As explained on this wiki page, only a single SHA-256 hash is used for generating the hash-160. For the checksum, however, (the first 4 bytes of) a double SHA-256 hash is used.
– Steven RooseJan 22 '14 at 22:14

Since you speak of a more responsible use of a shared resource, how can burning Bitcoin be seen as responsible? There is a finite number, each temporarily owned by some individual - it is easy to show that title to your property passes when you do. A company could not legitimately burn any Bitcoin that they possess any more than a company could burn cash - it is not in the best interest of the company. Burning Bitcoin rather than spending is no more responsible than burning your paycheck every week - you deprive yourself and the rest of the shared economy of the benefit when it is spent.
– WilltechApr 23 '18 at 9:42

Come up with an address that passes the basic sanity checks but is internally invalid. You can know for sure that no key could possibly match this address.

Put strings of characters in the address that are way beyond what anyone could generate in a vanity address. For example, if the Bitcoin address has "FourScoreAndSevenYearsAgo" in it, it's clearly beyond anyone's capability to find a corresponding private key.

Use a public key that's obviously made up, such as one that consists only of zero bytes or that contains all consecutive digits of Pi. It's clearly beyond anyone's capability to find a corresponding private key. (For this one to work, you need to disclose the public key.)

Use a hash of the public key that's obviously made up. This works the same as the option above, but the difficulty would be in even finding a public key with such a hash, much less finding the corresponding private key.

Isn't point 1 technically wrong as DeathAndTaxes and ThePiachu have demonstrated? We can't know for sure that no one knows a valid key matching the address-hash since there's an infinite number of valid keys slotted into a limited amount of possible hash values.
– PacerierMar 10 '14 at 14:15

@Pacerier The address would be internally invalid if we pick point 1. No key could match that address. You can slot an infinite number of things into a finite number of slots and still know for sure that some slots are empty. There are an infinite number of integers and a finite number of English words for categories, yet no integer falls into the category denominated by the word "angel".
– David SchwartzMar 10 '14 at 14:16

What is the catch? As normally you'd generate the public key from a private key and hash it a couple times, in order to retrieve coins from the address you generated, one would have to find such a specific number in point 1, that after points 2 and 3 would generate your bogus number. The chance of you finding one is about 1 in 2^160, which is impossible at current computation speeds. The more orderly the number you used in point 3 is, the more people would believe that it is an obviously fake address.

If you want to use an address, it would be nice to generate an address that can be verified by a human as obviously unspendable just by looking at the Base58. When you look at these addresses, you will say, "wow, that is obviously unspendable."

1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- used by Counterparty

1ChancecoinXXXXXXXXXXXXXXXXXZELUFD <- used by Chancecoin

These addresses are characterized by a human-readable identifier at the start, followed by a large number of X's. In order to spend the funds from an address like this, you would need to first reverse the hash (impossible), then find the private key that corresponds to the public key that you got (also impossible).

Note that the last six digits of these addresses are Base58Check checksums. This is the only tricky part of the process: you need to search over about 4 billion strings until you find a valid Base58Check string. This will only take an instant, though. You can easily generate these addresses using adamkrellenstein/unspendable on GitHub.

The methods described by DeathAndTaxes are appropriate. The OP_RETURN method is clearly the best if you want to adhere to the bitcoin recommendations.

However, I would like to present an alternative method where you can provably burn coins and also include sufficient information in the address. We used this method in the first versions of OpenBazaar and it is called an "almost-collision coin burning".

The de facto standard for burning coin in bitcoin is through an OP-RETURN script. This script has the important advantage that it contributes to bitcoin’s network scalability, as it allows full nodes to prune their UTXO when proof of burn transactions are detected. The mechanism employed to achieve that is simple: While a UTXO is maintained for all unspent regular transactions, when an OP-RETURN transaction is received by a full node, the full node can avoid adding that transaction to the UTXO completely, as the OP-RETURN script constitutes a proof that the amount remains unspendable and hence no future transaction can attach this dangling output to its input; it is hence a permanent dangling output edge.

OP-RETURN scripts work by having the first operator of the bitcoin script be an OP-RETURN, indicating an immediate exception in the execution of the script, hence making spending impossible. After the initial OP-RETURN operator, the rest of the script data can contain information about why the coin was burned, so that different applications can demand different burning, and so that the association with an account is possible. For example, in OpenBazaar’s case, it is important to associate the burned amount with an OpenBazaar GUID, which can be included as non-executable code after the OP-RETURN. The fact that this code is non-executable follows from that it will never be executed due to the earlier exception. However, the OP-RETURN approach lacks certain usability properties that we wished to preserve in our OpenBazaar implementation. In particular, for simplicity of implementation and usage, as well as for separation of concern reasons, we decided that OpenBazaar does not need to include a bitcoin wallet implementation. Instead, the user can use any existing wallet software they wish. Hence, to make payments required by OpenBazaar, either for product purchases or for burn transactions, the user would have to utilize their wallet directly.

Today, wallets do not have the ability to create OP-RETURN scripts in any usable way. The only way to create burn transactions are through manual issuing of script commands by the user, which can be confusing or impossible to execute for an average user without a programming background. Furthermore, the OP-RETURN script must be associated with an OpenBazaar GUID, something that makes the inclusion of this ability in existing wallets harder. While a wallet software could offer an API to do that, we are not aware of such implementations just yet.

For these reasons, we designed an alternative mechanism for coin burning which uses simple standard pay-to-pubkey-hash transactions. These transactions are treated normally by the bitcoin full nodes, hence they are propagated as required. Furthermore, it is easy for regular wallets to create such transactions, and users can easily understand the process and make the payment without worrying that an unnecessary amount of money will be transferred and without requiring special programming knowledge.

Our schema for burning is based on the following cryptographic assumption, a resistance to an almost-collision: It is computationally infeasible to calculate two hash pre-image values x1, x2 such that:

||H(x1)- H(x1)|| < ε

Where the norm denotes the Hamming distance of two strings and ε is a small constant, in our case 1. This assumption is strongly supported by the fact that a hash function is cryptographically secure; if this equation did not hold, a collision would have been found, modulo one bit, which indicates the hash is broken up to almost all of its bits.

Under this assumption for H = RIPEMD160, our schema asks for the burner to take the ECDSA public key associated with their OpenBazaar identity and turn it into a bitcoin address by following the regular schema for 1-prefixed bitcoin addresses. Regular bitcoin addresses are generated from regular bitcoin ECDSA keys as shown in the standard bitcoin address generation algorithm.

To generate an address that is provably unspendable, the burner starts with their ECDSA OpenBazaar public key and applies the same process. However, the burner perturbates the first SHA256 hash by one bit before piping it to the RIPEMD160 hash. Specifically, they flip the last bit of the hash output. The rest of the process follows identically. Finally, the burner transfers the amount of coin they wish to burn to this generated address. I will now illustrate the properties of correctness, uniqueness, and security for this scheme.

Correctness. To verify the correctness of the burn, a third party performs the same transformation as the burner. They begin from the public ECDSA key of the OpenBazaar node whose trust they wish to verify and follow the bitcoin address generation process, applying the same perturbation as the burner after the SHA256 stage. Arriving at the final bitcoin address, the verifier then checks the blockchain for money that was sent to this address. This concludes that the burn an honest burner performs will be correctly verified by an honest verifier. (This is a significant advantage when compared to alternative schemes that do not contain why-burned information such as nothing-up-my-sleeve addresses.)

Uniqueness. Under the assumption that RIPEMD160 is hard to reverse and the fact that SHA256 is a cryptographically secure hash function, assumptions already made by bitcoin, the uniqueness of burn address for each OpenBazaar key follows directly.

Security. For this scheme to be secure, we must prove that the burned money cannot actually be spent by anyone. Indeed, if the money were spendable, the spender would have to know the private key associated with a public key which hashes to the perturbed SHA256 value. However, this would allow the generation of an almost-collision in RIPEMD160, as the public key that can be used for spending the burned money and the public key of the OpenBazaar identity would constitute pre-images of hashes that only differ by one bit. From the almost-collision resistance assumption, we conclude that this is computationally infeasible.

The almost-collision method of coin burning introduces scalability challenges for the bitcoin software. We were not concerned with such challenges in OpenBazaar for two reasons. First, we felt a failure for bitcoin to scale given the massive motivated community use of our primitive constitutes a security problem for bitcoin itself, which must be addressed without requiring players to behave fairly to the system. This is a problem for bitcoin, not OpenBazaar. If bitcoin is susceptible to denial-of-service attacks with such means, the use of bitcoin as a payment system must be reconsidered.

Second, most importantly because we support the bitcoin ecosystem and wish to provide suggestions for solving its scalability issues, they can in fact be eliminated if proof-of-burn transactions are accompanied by the pre-image before perturbation. The accompanying pre-image constitutes proof that the money is unspendable, similar to the way OP-RETURN scripts constitute proof of unspendability. As these pre-images will be publicly available on the OpenBazaar network, in case OpenBazaar becomes largely adopted, full bitcoin nodes can utilize the OpenBazaar network to detect prunable UTXO outputs which perform proof-of-burn through almost-collision pay-to-pubkey-hash scripts. Regardless, the optimizability of the payment network is of little concern to its financially motivated users and its technical implementation details remain an open research problem.

Overall, however, once the OP_RETURN method becomes a usable alternative, the other methods of burning should be eliminated for elegance and scalability.

This is a good as destroyed because if anyone could reverse engineer the private key for this address, then due to the vanity length, they could use the same method to reverse engineer the private key for any address. Or they were lucky in the same way as winning the lottery jackpot each week for a year is lucky.

This fails the "How can an address for bitcoin destruction be selected that everyone can be reasonably sure no-one's going to know the private keys to spend the destroyed bitcoins?" requirement. How do I know that you didn't save the private key, or remember it?
– mcaMay 26 '14 at 4:37