New BIP: Revocable Proof-of-Burn Transaction Template #1362
Conversation
| version: 0x3 | ||
| marker: 0x0 | ||
| flag: 0x1 | ||
| txin_count: 0x1 |
There was a problem hiding this comment.
Why only a single input per transaction?
There was a problem hiding this comment.
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.
| witness_script: <taproot_witness> | ||
| </pre> | ||
|
|
||
| *The RPoB transaction input MUST be P2TR (Pay to Tap Root). |
There was a problem hiding this comment.
Again, to optimize for low complexity for SPV clients. Please the comment above.
| <pre> | ||
| 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. |
There was a problem hiding this comment.
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.
bip-rpob-tx-template.mediawiki
Outdated
|
|
||
| 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 new service bit to allow nodes to signal that this new type of standard transaction is accepted. |
There was a problem hiding this comment.
Service bits and BIPs are not applicable to node policies, which each and every node operator decides for himself.
There was a problem hiding this comment.
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.
bip-rpob-tx-template.mediawiki
Outdated
|
|
||
| <code><32-byte-revocation-puzzle> (if revoked: <32-byte-revocation-puzzle-preimage>)</code> | ||
|
|
||
| *Since the digest algorithm is double sha256, even for a very large number of revocation, this index would be very cheap to verify. |
There was a problem hiding this comment.
Updated, to state that it is in contrast to, for example, having revocations that are based upon a cryptographic signature.
bip-rpob-tx-template.mediawiki
Outdated
| The secondary purpose is to allow for untrusted parties to create transactions on your behalf. i.e. a 'RPoB' transaction creation service. | ||
| ===Why waste precious block space?=== | ||
|
|
||
| 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. |
There was a problem hiding this comment.
This sounds like an attack on Bitcoin.
There was a problem hiding this comment.
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.
|
|
||
| ===Why must the revocation output be of zero value?=== | ||
|
|
||
| Revocation can be spent by anyone once the revocation pre-image has been published. |
There was a problem hiding this comment.
Why does it need to be spent at all? It's a one-way signal, right? There's no double-spending to concern with...
There was a problem hiding this comment.
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
the
bip-rpob-tx-template
branch
from
bf38078
to
432e3cc
Compare
* 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.
veleslavs
force-pushed
the
bip-rpob-tx-template
branch
from
432e3cc
to
740d75f
Compare
|
Expanded the document to include details on using a Taproot Tweak to privately embed a fixed purpose to the transaction: This part of the document could really benefit from some review, in particular the nuances of making the verification work according to good practices. |
|
Hello @veleslavs, are you still working on this proposal? Has this idea been discussed on the mailing list? |
murchandamus
added
PR Author action required
|
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. |
This BIP proposes a standard way for making Bitcoin Proof-of-Burn Transactions.
There are many possible applications, such as being:
Please view the proposal here:
https://github.com/veleslavs/bips/blob/bip-rpob-tx-template/bip-rpob-tx-template.mediawiki
Next steps:
Upon assignment of a BIP number, I will update and convert this Draft Pull Request into a normal Pull Request.