Burn addresses

[casey]

I'd like to come up with a burn address format. I'm thinking bech32m, burn1…, with an arbitrary binary payload. The output script is then OP_RETURN PAYLOAD.

[tyjvazum]

Is the intention to actually burn a sat, or would the inscription simply be "burned" at the ord protocol level?

[casey]

Intention is to burn the sat, since that's simple and sending to an OP_RETURN is already extremely well understood. We could then recognize this in block explorers, but I don't think we need to do anything at the ord protocol level. Like the block explorer, when it sees a sat go to an OP_RETURNS, can display 🔥 BURNED 🔥 to represent being burned, somewhere in the /inscriptions page.

[tyjvazum]

Perhaps I'm missing something, but that seems extreme to me if the goal is just to mark an inscription as burned, when it could be done within the protocol without burning any sats. I'm assuming you'd at least want to handle cases where the sat is rare, epic, or legendary differently (or at a minimum provide a warning to the user), which would have added complexity. How is burning a sat simpler than creating a concept for burning in the protocol envelope?

[casey]

How is burning a sat simpler than creating a concept for burning in the protocol envelope?

A very reasonable question!

1. Burning a sat is already a well-defined and well-understood concept in Bitcoin.
2. A burn1… address with a payload allows including arbitrary messages at burn time.
3. A burn1… address relies on existing functionality (sending to an address) and it will be easy for users to understand.
4. New protocol additions require research, implementation, review, and ongoing maintenance, and we must figure out how they fit into the protocol.
5. We can allow burning a sat and inscription via sending to an OP_RETURN first, and then strategically consider if any use-cases that aren't served are worth the additional protocol level complexity.
6. The protocol already has to deal with burned sats, since you can already send sats to an op return. We'd just be enabling users to do what's already possible.
7. If you can burn an inscription via an ord-protocol envelope, it complicates the SPV security model, since they then need to look at all historical witnesses, not just first witness from inscribe, and TX-path to current TX.
8. An ord-protocol envelope adds size to the transaction.

I am hoping that the only ord-protocol witness envelope we need will be on inscribe, and plan to push as much as possible onto already existing functionality on the base layer.

[casey]

If burn addresses have plain-text payloads, we should have that text be visible to the user. Sending to a burn address is like making a statement, and we wouldn't want users to be tricked into statements they don't agree with. See sketch in #1657 for why this might be important.

[onchainguy-btc]

@casey was checking #2597 and then jumped to this issue. Was thinking to implement the burn but had 2 questions:

1. Why even have a burn address and not send to OP_RETURN output only?
2. If sending to OP_RETURN only, would you add that functionality to the transaction_builder.rs? It might need a refactoring because it currently only accepts Address outputs.

[onchainguy-btc]

@raphjaph what's your opinion on this? Would love to start working on this feature.

[casey]

I think a burn address standard is only useful if it's going to be used by wallets other than ord. If it's only supported by ord, then we can just add a --burn option to the various commands.

[onchainguy-btc]

Implemented in #2766

[onchainguy-btc]

New PR with #3437