From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 83BE8C002D for ; Thu, 25 Aug 2022 19:24:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4E19E418A9 for ; Thu, 25 Aug 2022 19:24:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4E19E418A9 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=zNykJAn9 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7t4DkkUXmRU for ; Thu, 25 Aug 2022 19:24:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B772741870 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by smtp4.osuosl.org (Postfix) with ESMTPS id B772741870 for ; Thu, 25 Aug 2022 19:24:25 +0000 (UTC) Date: Thu, 25 Aug 2022 19:24:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1661455462; x=1661714662; bh=g2UoRxmdR+qUAAGVOj8ZHu7HGVfJq0PHxXZ/LRysmAQ=; h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc: Date:Subject:Reply-To:Feedback-ID:Message-ID; b=zNykJAn9+R+RnmRUR2bxVWnA051ltV5oUmHSMkilq3Mah1W9qXtg8DnIbXpByf/zP 2Zq5+dNHpXilgKmIU8qp7AXyP0bZ82BlMSvPVm40GbRPf4b+X7UGRFaJPewCVBnG88 BQfNG1dzVSsUWXKNErGawmlJhmUZ68DHNqgmfk1f14NJmL7Du179yvRPaFo6HCUkzq OwCmma96x6KBvCPQV0o9ptCOQ6A+FiatFgFcO1EpCkXsg10CD4mGttFOPB6vwbyB0M HA9kTLlcUpZx6kSz+yEkpNNvyFfSeba/lR07guJ0LxCVg3qD4maENaYi4MRvHdILhp 5bR75TCSKzoYw== To: Bitcoin Dev From: =?utf-8?B?0JLQtdC70LXRgdC70LDQsg==?= Reply-To: =?utf-8?B?0JLQtdC70LXRgdC70LDQsg==?= Message-ID: Feedback-ID: 3024060:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 25 Aug 2022 20:27:16 +0000 Subject: [bitcoin-dev] BIP Draft: Revocable Proof-of-Burn Transaction Template X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2022 19:24:28 -0000 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
  BIP: bip-rpob-tx-template
  Layer: Applications
  Title: Revocable Proof-of-Burn Transaction Template
  Author: Veleslav 
  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
=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 theoryEvolutionary biology theory of comm= unication, or ''"signalling theory"'', where creatures make honest signals = that are hard to cheat, for mutual evolutionary advantage., proof of = burnIn 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. is a costly signal,A ''"costly signal"''= indicates dedication, an observer expects that such a signal is not made f= lippantly because the high cost. allowing the network to assign a def= ault trust.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. Bitcoin naturally pr= ovides an implementation of proof of burn without feedback loops,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. allowing for default = trust to be assigned fairly in decentralised networks.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. The ability to revokeTo ''"revoke", is'' publicly asser= ting that a previous statement should not be valued as originally intended.= past assertions is important for many applications,Unexpected things happen, for example, the loss or compromise of private= keys. 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 =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 SPV 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:
version:      0x3
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) 0x03. *RPoB transactions MUST have only one input and either two or three outputs= . =3D=3D=3DInput 1: Funding=3D=3D=3D General form:
signature_script:  (empty)
witness_script:    
*The RPoB transaction input MUST be P2TR (Pay to Tap Root). =3D=3D=3DOutput 1: Burn and Data=3D=3D=3D 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 unspendab= le by the 'OP_RETURN' in the public key script. =3D=3D=3DOutput 2: Revocation Puzzle=3D=3D=3D 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_revo= cation_solution that is derived from the secret key used to generate= the rpob_secp256k1_public_key . =3D=3D=3DOutput 3, Optional: Change=3D=3D=3D
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. =3D=3D=3DSignature: Included in Output 1=3D=3D=3D
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>
*The rpob_schnorr_signature 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: <32-byte-revocation-puzzle> (if revoked: <32-byte-revocation-puzzle-p= reimage>) *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