New BIP: Revocable Proof-of-Burn Transaction Template

veleslavs commented at 11:16 pm on August 31, 2022: contributor

This BIP proposes a standard way for making Bitcoin Proof-of-Burn Transactions.

There are many possible applications, such as being:

The default trust anchor in decentralised networks.
An effective dos-resistant signal for announcements or other low-frequency events.

Please view the proposal here: https://github.com/veleslavs/bips/blob/bip-rpob-tx-template/bip-rpob-tx-template.mediawiki

Next steps:

Update proposal with BIP Number.
Collect more peer-review.
Collect review in particular with the Taproot Tweak Parts.
Update BIP with reference implementation and test vectors.
Merge proposal as Draft BIP.

Upon assignment of a BIP number, I will update and convert this Draft Pull Request into a normal Pull Request.

draft: bip-rpob-tx-template 3699419db1

spelling: fix Signiture > Signature 2f6e1af500

in bip-rpob-tx-template.mediawiki:79 in 2f6e1af500 outdated

74+General form:
75+<pre>
76+version:      0x3
77+marker:       0x0
78+flag:         0x1
79+txin_count:   0x1

luke-jr commented at 10:43 pm on September 29, 2022:

Why only a single input per transaction?

veleslavs commented at 1:17 pm on October 23, 2022:

Hello @luke-jr, thank you for your initial review.

A transaction that has many inputs could be quite large; it is a requirement that this design is optimized for SPV performance. - Hence the restriction.

I have updated and expanded the ‘Other Requirements’ section: https://github.com/veleslavs/bips/blob/bip-rpob-tx-template/bip-rpob-tx-template.mediawiki#other-requirements

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; Exclusive use of Taproot, used to limit the complexity of the RPoB transactions.

in bip-rpob-tx-template.mediawiki:95 in 2f6e1af500 outdated

90+<pre>
91+signature_script:  (empty)
92+witness_script:    <taproot_witness>
93+</pre>
94+
95+*The RPoB transaction input MUST be P2TR (Pay to Tap Root).

luke-jr commented at 10:44 pm on September 29, 2022:

Why?

veleslavs commented at 1:18 pm on October 23, 2022:

Again, to optimize for low complexity for SPV clients. Please the comment above.

in bip-rpob-tx-template.mediawiki:112 in 2f6e1af500 outdated

107+The public key script fields are:
108+
109+<pre>
110+rpob_version_flag:           1-byte , 0x00 (initial version).
111+rpob_secp256k1_public_key:  32-bytes, SECP256K1 compact public key.
112+rpob_schnorr_signature:     64-bytes, bip-340 Schnorr Signature.

luke-jr commented at 10:45 pm on September 29, 2022:

Why?

veleslavs commented at 1:23 pm on October 23, 2022:

This signature protects the transaction from malleability when made by a second party.

–

I have added the following to the “Signature: Included in Output 1” section:

The signature is included so that the RPoB transaction may be safely constructed and funded by untrusted second parties.

in bip-rpob-tx-template.mediawiki:178 in 2f6e1af500 outdated

173+
174+==Deployment==
175+
176+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.
177+
178+If this standard gains significant attention, we are happy to write a supplementary BIP to define a new service bit to allow nodes to signal that this new type of standard transaction is accepted.

luke-jr commented at 10:46 pm on September 29, 2022:

Service bits and BIPs are not applicable to node policies, which each and every node operator decides for himself.

veleslavs commented at 1:24 pm on October 23, 2022:

Thank you, I have updated the document to better reflect the intentions:

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.

in bip-rpob-tx-template.mediawiki:191 in 2f6e1af500 outdated

186+
187+The hash-puzzle allows for easy indexing of the revocation, in the format:
188+
189+<code><32-byte-revocation-puzzle> (if revoked: <32-byte-revocation-puzzle-preimage>)</code>
190+
191+*Since the digest algorithm is double sha256, even for a very large number of revocation, this index would be very cheap to verify.

luke-jr commented at 10:47 pm on September 29, 2022:

?

veleslavs commented at 1:36 pm on October 23, 2022:

Updated, to state that it is in contrast to, for example, having revocations that are based upon a cryptographic signature.

in bip-rpob-tx-template.mediawiki:208 in 2f6e1af500 outdated

203+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).
204+
205+The secondary purpose is to allow for untrusted parties to create transactions on your behalf. i.e. a 'RPoB' transaction creation service.
206+===Why waste precious block space?===
207+
208+Consuming block-space is a of secondary proof-of-burn that this proposal takes advantage of, as itself is limited and contested for (blocks are almost full on average). There is an opportunity cost of the next best transaction when a miner chooses to include a RPoB transaction their block.

luke-jr commented at 10:51 pm on September 29, 2022:

This sounds like an attack on Bitcoin.

veleslavs commented at 1:29 pm on October 23, 2022:

We didn’t quite comprehend what attack you we specially referencing. However, we took some time to expand on this point to make our intentions and philosophy more clear:

–

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.

in bip-rpob-tx-template.mediawiki:199 in 2f6e1af500 outdated

194+
195+Additionally, we do not want to confuse a public key, (that can sign), and a revocation-puzzle (that may only revoke).
196+
197+===Why must the revocation output be of zero value?===
198+
199+Revocation can be spent by anyone once the revocation pre-image has been published.

luke-jr commented at 10:55 pm on September 29, 2022:

Why does it need to be spent at all? It’s a one-way signal, right? There’s no double-spending to concern with…

veleslavs commented at 1:32 pm on October 23, 2022:

We think that this is a very good point and expanded on the topic in the “Other Requirements” section: https://github.com/veleslavs/bips/blob/bip-rpob-tx-template/bip-rpob-tx-template.mediawiki#other-requirements

In summary, including the revocation in the block chain makes them uncensorable, in contrast to a gossip network.

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

veleslavs force-pushed on Oct 23, 2022

add fixed purpose and various clarifications

* Explicitly note using Taproot Tweaks for locking a RPoB to a particular purpose. (Needs more review by someone more experience in the details of Taproot.)
* Changed the nVersion from 3 to 5. (Other proposals already plan of using version 3).
* Clarified details about the use of block space and fees.

740d75f635

veleslavs force-pushed on Oct 23, 2022

veleslavs commented at 1:41 pm on October 23, 2022: contributor

Expanded the document to include details on using a Taproot Tweak to privately embed a fixed purpose to the transaction:

https://github.com/veleslavs/bips/blob/bip-rpob-tx-template/bip-rpob-tx-template.mediawiki#optional-fixed-purpose-encoded-in-the-key-tweak

This part of the document could really benefit from some review, in particular the nuances of making the verification work according to good practices.

manda2020panda approved

murchandamus commented at 6:03 pm on May 1, 2024: contributor

Hello @veleslavs, are you still working on this proposal? Has this idea been discussed on the mailing list?

murchandamus added the label PR Author action required on May 8, 2024

murchandamus added the label New BIP on May 8, 2024

5twelve approved

murchandamus commented at 8:01 pm on July 10, 2024: contributor

I’m closing this PR because work on this unfinished draft appears to have stopped more than one and a half years ago and there was no reaction to my prior liveliness check. If this assessment is mistaken, please feel free to open a new pull request.

murchandamus closed this on Jul 10, 2024

New BIP: Revocable Proof-of-Burn Transaction Template #1362