Date: Thu, 25 Aug 2022 19:24:16 +0000
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
From: =?utf-8?B?0JLQtdC70LXRgdC70LDQsg==?= <veleslav.bips@protonmail.com>
Reply-To: =?utf-8?B?0JLQtdC70LXRgdC70LDQsg==?= <veleslav.bips@protonmail.com>
Message-ID: <emmQNdTtCoPOwRQ7xjUN937V30qIsadPo2a0LW_QdAgKwFTSRWhYLHAfrDsa6ow2Yw08HPRH0cPDEq5zgHhVJEz6n0XVP_hDNcJzTEvtrv0=@protonmail.com>
Feedback-ID: 3024060:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] BIP Draft: Revocable Proof-of-Burn Transaction
	Template
Precedence: list

Dear Bitcoin Development Mailing List,

I would like to present for initial comment a new draft BIP that we have be=
en working on.

This BIP provides a new standard template for creating revocable proof-of-b=
urn transactions that can be easily and cheaply verified by nodes running u=
nder SPV assumptions.

We would very much appreciate further peer-feedback and critical comment so=
 that this proposal may be improved as it continues through the formal stan=
dardisation process.

Please find the full draft-proposal appended, you may also use the link pro=
vided to view the online rendered copy.

Yours sincerely,
Veleslav


PS. Upon being assigned a BIP-Number, I will write to the list with the upd=
ated URL.

https://github.com/veleslavs/bips/blob/bip-rpob-tx-template/bip-rpob-tx-tem=
plate.mediawiki


<pre>
  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
</pre>

=3D=3DIntroduction=3D=3D

=3D=3D=3DAbstract=3D=3D=3D
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 e=
xtensions.
* This proposal recommends that implementations who mine and relay transact=
ion to update their standard transaction templates as defined by this docum=
ent.

This proposal aims to support decentralised systems, allowing the use ''RPo=
B'' assertions in a consistent, efficient, reliable, and interoperable way.

''The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU=
LD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document ar=
e to be interpreted as described in RFC 2119.''

=3D=3D=3DCopyright=3D=3D=3D
This document is dual licensed as BSD 3-clause and Creative Commons CC0 1.0=
 Universal.

=3D=3D=3DMotivation=3D=3D=3D
In signalling theory<ref group=3D"Note">Evolutionary biology theory of comm=
unication, or ''"signalling theory"'', where creatures make honest signals =
that are hard to cheat, for mutual evolutionary advantage.</ref>, proof of =
burn<ref group=3D"Note">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. Tran=
sferring the network wealth onto the remaining coins that have a non-zero v=
elocity.</ref> is a costly signal,<ref group=3D"Note">A ''"costly signal"''=
 indicates dedication, an observer expects that such a signal is not made f=
lippantly because the high cost.</ref> allowing the network to assign a def=
ault trust.<ref group=3D"Note">An entity is assigned a ''"default trust"'' =
value when they are not connected to the trust graph. Without a default sou=
rce trust, growing a decentralised web-of-trust network is impossible. New =
users face a catch-22 problem: they are disconnected from the trust graph a=
nd don't have a possibility to prove themselves.</ref> Bitcoin naturally pr=
ovides an implementation of proof of burn without feedback loops,<ref group=
=3D"Note">A ''"feedback loop"'' is when a trust signal can be amplified by =
a privileged subset of the network by feeding the creation-cost of this sig=
nal back into the process of making the signal.</ref> allowing for default =
trust to be assigned fairly in decentralised networks.<ref group=3D"Note">N=
ew users are able to use a proof-of-burn to bootstrap themselves into new t=
rust networks. 'New-user-with-burn-proofs' can be welcomed-in with basic se=
rvices and focused attention, as the network knows that it was costly to ge=
nerate the burn-proof.</ref>

The ability to revoke<ref group=3D"Note">To ''"revoke", is'' publicly asser=
ting that a previous statement should not be valued as originally intended.=
</ref> past assertions is important for many applications,<ref group=3D"Not=
e">Unexpected things happen, for example, the loss or compromise of private=
 keys.</ref> therefore proposal couples bitcoin proof-of-burn with a revoca=
tion mechanic.

In choosing to standardise via the BIP peer-reviewed process, we hope to gi=
ve the community greater confidence in making use of bitcoin-based revocabl=
e proof of burn technology.

=3D=3D=3D=3DNotes:=3D=3D=3D=3D
<references group=3D"Note" />

=3D=3DDesign=3D=3D

=3D=3D=3DConceptual=3D=3D=3D
''"Proof-of-Burn"'' transactions have long exited in Bitcoin, ''"OP_RETURN"=
'' transactions, (named after the op-code ''"return"'', that causes the pub=
lic key script to return in failure, hence making the output unspendable an=
d "burning" any value allocated to that output), these transactions have be=
en 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 requiremen=
ts a application-useable proof-of-burn transaction, in particular:

*A standard association with a public key in for transaction.
*A standard protocol to publicly revoke a proof-of-burn transaction.

In this proposal we satisfy these requirements by specifying a taproot publ=
ic key in the op_return payload and an another output for revocation.

=3D=3D=3DOther Requirements=3D=3D=3D
Operation under <abbr title=3D"Simple Payment Verification">SPV</abbr> assu=
mptions:
*Transactions are small: ''RPoB transactions (non-witness-part) are fixed t=
o two possible sizes, depending if there is a change output, or not.''
*Revocations are quickly and cheaply indexed: ''RPoB revocations only requi=
re obtaining the preimage to a double-sha256 hash. This is easily indexed a=
nd propagated in a gossip network.''

Ease of implementation:
*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.''

Transaction funded by 3rd party:
* It should be secure for an untrusted 3rd party fund the proof-of-burn tra=
nsaction. ''Allowing for services to fund these transactions and be compens=
ated with some sort of off-chain payment.''

Future extendability:
*Making use of the transaction version feature of bitcoin. ''This allows fo=
r 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 wa=
y to upgrade in the future in a forward-comparable way.''

=3D=3D=3DTransaction Design Overview:=3D=3D=3D
[[File:bip-rpob-tx-template/rpob-template-summary-table.svg]]

=3D=3DSpecification=3D=3D
This section specifies our RPoB transaction template.

=3D=3D=3DTransaction=3D=3D=3D
General form:
<pre>
version:      0x3
marker:       0x0
flag:         0x1
txin_count:   0x1
txout_count:  0x2 (without change) or 0x3 (with change)
lock_time:    (any)
</pre>

*RPoB transactions MUST use the transaction version (nVersion) 0x03.

*RPoB transactions MUST have only one input and either two or three outputs=
.

=3D=3D=3DInput 1: Funding=3D=3D=3D
General form:
<pre>
signature_script:  (empty)
witness_script:    <taproot_witness>
</pre>

*The RPoB transaction input MUST be P2TR (Pay to Tap Root).

=3D=3D=3DOutput 1: Burn and Data=3D=3D=3D
General form:

<pre>
value:              (any)
public_key_script:  RETURN < 1-byte-rpob_version_flag>
                           <32-byte-rpob_secp256k1_public_key>
                           <64-byte-rpob_schnorr_signature>
</pre>

The public key script fields are:

<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.
</pre>

*The first RPoB transaction contains the burn value, that is made unspendab=
le by the 'OP_RETURN' in the public key script.

=3D=3D=3DOutput 2: Revocation Puzzle=3D=3D=3D
General form:

<pre>
value:              0
public_key_script:  SIZE 32 EQUALVERIFY HASH256
                    <32-byte-rpob_revocation_puzzle>
                    EQUAL
</pre>

*The Value of the Revocation Puzzle Output MUST be zero.

<code>HASH256</code> is defined by ''double sha256'':

<pre>
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.
</pre>

*It is RECOMMENDED that implementations use a value for the <code>rpob_revo=
cation_solution</code> that is derived from the secret key used to generate=
 the  <code>rpob_secp256k1_public_key</code> .

=3D=3D=3DOutput 3, Optional: Change=3D=3D=3D
<pre>
value:              (any)
public_key_script:  1 <32-byte-taproot_witness_program>
</pre>

*This output MAY have any value.
*The public key MUST be a standard P2TW output.

=3D=3D=3DSignature: Included in Output 1=3D=3D=3D
<pre>
rpob_schnorr_signature:       64-bytes, bip-340, signature (
                                        <32-byte-rpob_signature_message_has=
h>,
                                        <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>
</pre>

*The <code>rpob_schnorr_signature</code> uses the [https://github.com/bitco=
in/bips/blob/master/bip-0340.mediawiki BIP-340] algorithm.

=3D=3DDeployment=3D=3D

While the ''IsStandard'' rules are quite restricting, it is quite possible =
to submit transactions directly to miners, or co-operate with miners who wo=
uld enjoy to have some addition fee-revenue. So the initial process of test=
ing on the main-network should be possible.

If this standard gains significant attention, we are happy to write a suppl=
ementary BIP to define a new service bit to allow nodes to signal that this=
 new type of standard transaction is accepted.

=3D=3DRationale=3D=3D
=3D=3D=3DWhy require RPoB transactions to use a new transaction version?=3D=
=3D=3D

This allows for future indexing and enforcement strategies at the consensus=
 layer.

=3D=3D=3DWhy use a hash puzzle for the revocation?=3D=3D=3D

The hash-puzzle allows for easy indexing of the revocation, in the format:

<code><32-byte-revocation-puzzle> (if revoked: <32-byte-revocation-puzzle-p=
reimage>)</code>

*Since the digest algorithm is double sha256, even for a very large number =
of revocation, this index would be very cheap to verify.

*We envision nodes keeping track of all the revocation-puzzles listed in th=
e blockchain, as 32-byte each, a million RPoB is only 32mb. This can be fur=
ther optimised.

Additionally, we do not want to confuse a public key, (that can sign), and =
a revocation-puzzle (that may only revoke).

=3D=3D=3DWhy must the revocation output be of zero value?=3D=3D=3D

Revocation can be spent by anyone once the revocation pre-image has been pu=
blished.

=3D=3D=3DWhy does a RPoB need a signature at all?=3D=3D=3D

The primary purpose of the signature is to stop replay-attacks. (Somebody t=
akes your public-key and makes transaction where you don't control the revo=
cation).

The secondary purpose is to allow for untrusted parties to create transacti=
ons on your behalf. i.e. a 'RPoB' transaction creation service.
=3D=3D=3DWhy waste precious block space?=3D=3D=3D

Consuming block-space is a of secondary proof-of-burn that this proposal ta=
kes advantage of, as itself is limited and contested for (blocks are almost=
 full on average). There is an opportunity cost of the next best transactio=
n when a miner chooses to include a RPoB transaction their block.

Additionally, transaction fees are important for the long-term health of th=
e bitcoin-network, this proposal increases the demand for the blockchain.

=3D=3D=3DWhat do you want to make these RPoB transactions if there is insuf=
ficient block-space?=3D=3D=3D

This isn't our problem. Those who have the economic purpose and resources t=
o make RPoB transactions will outcompete those who do not.

=3D=3DBackwards Compatibility=3D=3D

As this is an application layer structure without any preexisting deploymen=
t, we foresee no compatibility issues.

=3D=3DReference Implementation=3D=3D

To be made.

=3D=3DAcknowledgements=3D=3D

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 contrib=
utions.

=3D=3DAppendixes=3D=3D

=3D=3D=3DAppendix 1: Some alternatives to blockchain-based proof-of-burn:=
=3D=3D=3D
Blockchains provide the our first opportunity to have deterministic and dec=
entralised trust networks. Before blockchains we had proof-of-work and proo=
f-of-payments as the two main gate-keepers for boot-scraping new members in=
to a exclusive group:

=3D=3D=3D=3D Proof-of-Work: =3D=3D=3D=3D
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.

With proof-of-work blockchains provides a way to quantises an abstract an a=
mount of work into a value. Providing a solution "how much dose this work c=
ost?" problem: your work can be traded for bitcoin, and the bitcoin value i=
s set efficiently in the market.

=3D=3D=3D=3D Proof-of-Payment: =3D=3D=3D=3D
For example,

* Buying an expensive uniform item required for the clan.
* Paying membership dues.
* Proving a donation to a charity.

With proof-of-payment the problem is the feedback loops, who gets the payme=
nt is placed into a privileged position of responsibly. The blockchain solv=
es this with proof-of-burn outputs, the 'payment' goes back to the network,=
 distributed indirectly and proportionally the holders of bitcoin.

=3D=3D=3D=3D None: =3D=3D=3D=3D
For example,

* Pretty-Good-Privacy (PGP).

PGP provided the basic cryptographic infrastructure for secure communicatio=
n, including a basic web-of-trust where users can cross-sign each others ke=
ys, to make man-in-the-middle attacks harder to carry out. The primary prob=
lem with PGP is that any infrastructure that uses it is open to denial-of-s=
ervice attack, as making new pgp-key identities is extremely cheap.

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-ge=
nuine trust network.

=3D=3D=3D=3D Other: =3D=3D=3D=3D

* Blockchain Timestamping, i.e. Open-Timestamps.

One of the most simple ways of assiging value to something is to prove that=
 it is old. Timestamping with a blockchain allows users to assert that they=
 didn't just create this account just now. -  However the problem is that t=
imestamps are cheap to make, and if the need for timestamps is predictable,=
 then adversaries can pre-generate many to misuse and attack a network at a=
 later date.

* Blockchain space Use.

Simply putting a statement into a blockchain itself, if there is any free-p=
ressure is indirect form of burn by via the miner.  By out-competing the ne=
xt-best-transaction set, this has burnt the value in the difference between=
 the fees of the two set.

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!

=3D=3D=3D Appendix 2: Some notes on blockchain-based proof-of-burn and dece=
ntralised networks: =3D=3D=3D
Using a blockchain the relative value of a proof-of-burn is deterministical=
ly calculable:

* Trust calculations transferring a proof-of-burn into a "default trust" va=
lue are possible. Leading to the creation of trust graphs that can operate =
reliably without human intervention.
* Networks using such default trust calculations become inherently resistan=
t to distributed denial of service attacks.

All this cannot easily be achieved without leveraging the functionally of a=
 blockchain such as Bitcoin.

=3D=3DFootnotes=3D=3D

<references />