BIP: bip-rpob-tx-template
Layer: Applications
Title: Revocable Proof-of-Burn Transaction Template
Author: Veleslav <veleslav.bips@protonmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-bip-rpob-tx-template
Status: Draft
Type: Standards Track
Created: 2022-08-18
License: BSD-3-Clause
CC0-1.0
This BIP proposes an application-layer template for revocable proof-of-burn, or "RPoB", transactions.
- This proposal uses a new transaction version number to allow for future extensions.
- This proposal recommends that implementations who mine and relay transaction to update their standard transaction templates as defined by this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This document is dual licensed as BSD 3-clause and Creative Commons CC0 1.0 Universal.
In signalling theory[Note 1], proof of burn[Note 2] is a costly signal,[Note 3] allowing the network to assign a default trust.[Note 4] Bitcoin naturally provides an implementation of proof of burn without trust feedback loops,[Note 5] allowing for default trust to be assigned fairly in decentralised networks.[Note 6]
The ability to revoke[Note 7] past assertions is important for many applications,[Note 8] therefore proposal couples bitcoin proof-of-burn with a revocation mechanic.
In choosing to standardise via the BIP peer-reviewed process, we hope to give the community greater confidence in making use of bitcoin-based revocable proof of burn technology.
- ^ Evolutionary biology theory of communication, or "signalling theory", where creatures make honest signals that are hard to cheat, for mutual evolutionary advantage.
- ^ In Bitcoin, proof of burn places bitcoin value into outputs that provably unspendable. This dose not reduce the wealthy of the network, but instead reduces the velocity of these coins to zero. Transferring the network wealth onto the remaining coins that have a non-zero velocity.
- ^ A "costly signal" indicates dedication, an observer expects that such a signal is not made flippantly because the high cost.
- ^ An entity is assigned a "default trust" value when they are not connected to the trust graph. Without a default source trust, growing a decentralised web-of-trust network is impossible. New users face a catch-22 problem: they are disconnected from the trust graph and don't have a possibility to prove themselves.
- ^ A "trust feedback loop" is when a trust signal can be amplified by a privileged subset of the network by feeding the creation-cost of this signal back into the process of making the signal.
- ^ New users are able to use a proof-of-burn to bootstrap themselves into new trust networks. 'New-user-with-burn-proofs' can be welcomed-in with basic services and focused attention, as the network knows that it was costly to generate the burn-proof.
- ^ To "revoke", is publicly asserting that a previous statement should not be valued as originally intended.
- ^ Unexpected things happen, for example, the loss or compromise of private keys.
"Proof-of-Burn" transactions have long exited in Bitcoin, "OP_RETURN" transactions, (named after the op-code "return", that causes the public key script to return in failure, hence making the output unspendable and "burning" any value allocated to that output), these transactions have been actively mined since the release of Bitcoin-Core 0.9.
Since OP_RETURN doesn't allow the public key script to be spent (as is it's design), there hasn't been any built-in solution addressing the requirements a application-useable proof-of-burn transaction, in particular:
- A standard association with a public key in for transaction.
- A standard way to privately lock a OP_RETURN transaction to a particular purpose.
- A standard protocol to publicly revoke a proof-of-burn transaction.
Optimized operation under SPV assumptions:
- Transactions are tiny and simple: The RPoB transactions template constrains the rules of the transaction to the minimum. Both size are complexity limitations are used: Single Input, used to limit the size of the RPoB transactions; Single Optional Change Output, used to limit the size of the RPoB transactions; and Exclusive use of Taproot, used to limit the complexity of the RPoB transactions.
- Revocations are both cheaply indexed and uncensorable: Receiving the pre-image to the RPoB revocation signals it's revocation. This is easily indexed and propagated in a gossip network, however gossip networks are relatively censorable. Using the same pre-image, anyone is able to spend the revocation output, rendering this revocation uncensorable.
- Use of only Taproot and Schnorr: To reduce the scope of the transaction, we use only Taproot for inputs and Outputs, and Schnorr for the signature that covers the funding outpoint.
- It should be secure for an untrusted 3rd party fund the proof-of-burn transaction. Allowing for services to fund these transactions and be compensated with some sort of off-chain payment.
- Making use of the transaction version feature of bitcoin. This allows for easier indexing strategies in the future, (with a simple consensus change: to include in the coinbase the number of the transactions in the block by their transaction version).
- Including a byte for 8 version flag bits. This allows for a reliable way to upgrade in the future in a forward-comparable way.
This section specifies our RPoB transaction template.
General form:
version: 0x5 marker: 0x0 flag: 0x1 txin_count: 0x1 txout_count: 0x2 (without change) or 0x3 (with change) lock_time: (any)
- RPoB transactions MUST use the transaction version (nVersion) 0x05.
- RPoB transactions MUST have only one input and either two or three outputs.
General form:
signature_script: (empty) witness_script: <taproot_witness>
- The RPoB transaction input MUST be P2TR (Pay to Tap Root).
General form:
value: (any)
public_key_script: RETURN < 1-byte-rpob_version_flag>
<32-byte-rpob_secp256k1_public_key>
<64-byte-rpob_schnorr_signature>
The public key script fields are:
rpob_version_flag: 1-byte , 0x00 (initial version). rpob_secp256k1_public_key: 32-bytes, SECP256K1 compact public key. rpob_schnorr_signature: 64-bytes, bip-340 Schnorr Signature.
- The first RPoB transaction contains the burn value, that is made unspendable by the 'OP_RETURN' in the public key script.
- The 'secp256k1_public_key' may be tweaked, showing the signed tweak (and it's associated pre-image) proves the single-purpose of the RPoB transaction.
General form:
value: 0
public_key_script: SIZE 32 EQUALVERIFY HASH256
<32-byte-rpob_revocation_puzzle>
EQUAL
- The Value of the Revocation Puzzle Output MUST be zero.
HASH256 is defined by double sha256:
rpob_revocation_puzzle: 32-bytes, public, SHA256(SHA256(
<32-byte-rpob_revocation_solution>
))
rpob_revocation_solution: 32-bytes, secret, publicly reveal this value to revoke the proof-of-burn.
- It is RECOMMENDED that implementations use a value for the
rpob_revocation_solutionthat is derived from the secret key used to generate therpob_secp256k1_public_key.
value: (any) public_key_script: 1 <32-byte-taproot_witness_program>
- This output MAY have any value.
- The public key MUST be a standard P2TW output.
rpob_schnorr_signature: 64-bytes, bip-340, signature (
<32-byte-rpob_signature_message_hash>,
<32-byte-secp256k1_private_key>
)
rpob_signature_message_hash: 32-bytes, bip-340, sha256_taged_hash (
<77-byte-rpob_signature_message>,
<16-byte-rpob_hash_tag>
)
rpob_hash_tag: 16-bytes, utf-8-hash_tag ("rpob/BTC/MAINNET")
or, utf-8-hash_tag ("rpob/BTC/TESTNET")
rpob_signature_message: 77-bytes, < 1-byte-version_flags>
<32-byte-input_txid_hash>
< 4-byte-input_index>
< 8-byte-burn_output_value>
<32-byte-rpob_revocation_puzzle>
- The signature is included so that the RPoB transaction may be safely constructed and funded by untrusted second parties.
The Tweak is applied to the public and secret keys the same as the 'TapTweak' hash in BIP-341:
rpob_secp256k1_public_key_tweaked: 32-bytes, bip-341, taproot_tweak_pubkey (
<32-byte-rpob_secp256k1_public_key>,
<32-byte-rpob_tweak_hash>
)
rpob_secp256k1_private_key_tweaked: 32-bytes, bip-341, taproot_tweak_seckey (
<32-byte-secp256k1_private_key>,
<32-byte-rpob_tweak_hash>
)
rpob_tweak_hash: 32-bytes, bip-340, sha256_taged_hash (
<rpob_transaction_purpose>,
<16-byte-rpob_tweak_hash_tag>
)
rpob_tweak_hash_tag: 16-bytes, utf-8-hash_tag ("rpob/BTC/PURPOSE")
The 'rpob_transaction_purpose', is a user defined string that locks the RPoB transaction to a particular purpose.
The Taproot Tweaks should be signed and revealed according to BIP-341.
While the IsStandard rules are quite restricting, it is quite possible to submit transactions directly to miners, or co-operate with miners who would enjoy to have some addition fee-revenue. So the initial process of testing on the main-network should be possible.
If this standard gains significant attention, we are happy to write a supplementary BIP to define a way for participating nodes signal to each other that they accept the relay of RPoB transactions.
This allows for future indexing and enforcement strategies at the consensus layer.
Locking a transaction to a particular purpose allows for users to prove globally that their RPoB transaction is not secretly having additional purposes. Often when making a proof-of-burn transaction a service will want to assure that the value burnt is not being spread over multiple purposes.
Tweaks provide a natural solution to this problem: 1. It is impossible to encode multiple top-level tweaks into the a public key. (Multiple tweaks are possible but this is not a problem as it demands using a different decoding process). 2. Privacy is maintained. Nobody can tell if a RPoB transaction has a fixed purpose, or not, unless the tweak has been revealed.
The hash-puzzle allows for easy indexing of the revocation, in the format:
<32-byte-revocation-puzzle> (if revoked: <32-byte-revocation-puzzle-preimage>)
- Since the digest algorithm is double sha256, even for a very large number of revocation, this index would be very cheap to verify, in contrast to asymmetrical cryptographic signatures.
- We envision nodes keeping track of all the revocation-puzzles listed in the blockchain, as 32-byte each, a million RPoB is only 32mb. This can be further optimised.
Revocation can be spent by anyone once the revocation pre-image has been published.
The primary purpose of the signature is to stop replay-attacks. (Somebody takes your public-key and makes transaction where you don't control the revocation).
The secondary purpose is to allow for untrusted parties to create transactions on your behalf. i.e. a 'RPoB' transaction creation service.
The authors of this BIP do accept the premise of this question. Each block is a auction of block-space that helps rewarding the miner in their important consensus role. We are not some authority who can define 'waste' from 'economic' transaction. We take the neutral position that if a transaction is willing to pay the transaction-fee-at-auction it must have a economic purpose that supports doing so.
Additionally, this proposal takes advantage of economic opportunity cost that the miner faces when excluding transaction when blocks are full (that they generally are). This allows for the transaction-fees-at-auction to behave as a secondary proof-of-burn.
The authors are not fazed by the possibility that proposal, if gaining significant adoption, will lead to the a meaningful increase of the Bitcoin transaction fees. We regard transaction fees important for long-term health of the network and consider making statements in global consensus networks as inherently costly.
This isn't our problem. Those who have the economic purpose and resources to make RPoB transactions will outcompete those who do not.
As this is an application layer structure without any preexisting deployment, we foresee no compatibility issues.
To be made.
While we have somewhat independently come up with the concept of RPoB, the idea of having a public record of public key enrolments has been around for a long time. None of the ideas in this BIP are new.
We would like to thank Jonas Schnelli, 'M', and 'P', for their past contributions.
Blockchains provide the our first opportunity to have deterministic and decentralised trust networks. Before blockchains we had proof-of-work and proof-of-payments as the two main gate-keepers for boot-scraping new members into a exclusive group:
For example,
- In games it could be to grind your character up to a certain level.
- Or it could be to make and present hand-drawn artworks.
- Or it could be to solve a CAPTCHA.
For example,
- Buying an expensive uniform item required for the clan.
- Paying membership dues.
- Proving a donation to a charity.
For example,
- Pretty-Good-Privacy (PGP).
The trust network also is open to sybil attack, as huge numbers of keys can all cross-trust each other making it appear that they belong to a large-genuine trust network.
- Blockchain Timestamping, i.e. Open-Timestamps.
- Blockchain space Use.
Thus, it can be shown that if the blocks are full, a RPoB transaction with zero-burn-amount is still a proof-of-bun transaction!
Using a blockchain the relative value of a proof-of-burn is deterministically calculable:
- Trust calculations transferring a proof-of-burn into a "default trust" value are possible. Leading to the creation of trust graphs that can operate reliably without human intervention.
- Networks using such default trust calculations become inherently resistant to distributed denial of service attacks.