From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 07BE241C for ; Sat, 25 Mar 2017 03:30:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 065191D6 for ; Sat, 25 Mar 2017 03:30:26 +0000 (UTC) Received: by mail-wr0-f194.google.com with SMTP id u1so992727wra.3 for ; Fri, 24 Mar 2017 20:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Ha7ZxdQYQsG2z3jCp8hdncIlcxLmPXbR/tyYApchE/g=; b=KWnybV+KfNeJKxFbW1llNLzHhdjvGuEijPPWeCAm/69xupKBSeK1zLJSFOH1jzGjro bEjfzSrkixoKsIYlzanf7e0zkSTIkheeydoSE+JdkIdALUrHgxUGkhLTB6QLlUt3ugle baiDecSji+4tuVVjTJOkq66iNv+WaPzXBZ0RAztAy3M+k1Vk8UQ0txTSvRRlomvi/8Rs 5vN5qUBYey+rUoPf7DlaKzjSDK1Nbb7GPb9EmD8nLiGglv2A74Jh9ka5G8TALdssQ2uG wWjLnp6AlxyQnTgjQCPsBUCZyXDxFMT1rMpBtoZRA35U3W7X8NBZeBBdGC/cgv4RjmUk d0Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Ha7ZxdQYQsG2z3jCp8hdncIlcxLmPXbR/tyYApchE/g=; b=TvinVZxJ5FOu/9beCWbYNZY9lBtgk8UNOvJYLov3hmLDg62Z8OfH00GVEBuvmB/QwY 3i2Hk+vEwLatjVqoqZ3GL+KeZKVJ0ohaop6Dzho0l892ksp8o5GdQRjH1f8KXJ1FOpIT 5ojOXt7iRI8IZ2qshrVbXxImSjJRQ49LsertA6c3VOiuBP3sQUXr0OcnyADhTGSCZ1/e d5sHP2Y1FgaQeteLYTDlxJ8lU8rU+RM4eel9Pa85h8uxHjPVIcfB/paRh1aMAqXEWiHy B5foW7QMd3w/aZulKUMAU5aqT/Jj8EQ19xiMiD9f1zbD/v7KNaIwUiMG58pYWGKQHG4g gQsA== X-Gm-Message-State: AFeK/H0unszJE967gMpQS4//0XLVCvKPeyzf0R5ts2OqG5wVgB+O4c1Bb1pG9d/viE4mbQ== X-Received: by 10.223.136.125 with SMTP id e58mr8668198wre.14.1490412625311; Fri, 24 Mar 2017 20:30:25 -0700 (PDT) Received: from camerons-mbp.odessa.tv ([78.26.162.5]) by smtp.gmail.com with ESMTPSA id n80sm2522645wrb.24.2017.03.24.20.30.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 20:30:24 -0700 (PDT) From: Cameron Garnham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <07F54C7C-5F26-446D-A479-7F81BD131151@gmail.com> Date: Sat, 25 Mar 2017 05:30:22 +0200 To: Bitcoin Protocol Discussion X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Strong Anti-Replay via Coinbase Transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 03:30:28 -0000 
  BIP: ???
  Layer: Consensus (soft fork)
  Title: Strong Anti-Replay via Coinbase Transactions
  Author: Cameron Garnham 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???
  Status: Draft
  Type: Standards Track
  Created: 2017-03-25
  License: BSD-3-Clause
           CC0-1.0
=3D=3DAbstract=3D=3D This document specifies a soft fork that enables users to make = transactions with a strong expectation that such transactions cannot be = replayed on a different chain. Important Note: In the case that an adversary hard-fork, the strong = guarantee of non-replayabilty via this BIP may not be supported. =3D=3DDefinitions=3D=3D =3D=3DMotivation=3D=3D In the case of a chain split, it is important to protect users from, = potentially significant, loss of funds from transaction replay attacks. =3D=3DSpecification=3D=3D Upon activation of the soft-fork (activation methodology undefined in = this proposal), the following new rules become activated on the Bitcoin = Network. New =E2=80=98anti-replay=E2=80=99 OpCode. Take an unused NoOp and = redefine it as =E2=80=98OP_ANTI_REPLAY=E2=80=99. The script must only have the form: scriptPubKey: (empty) scriptSig: OP_ANTI_REPLAY OP_ANTI_REPLAY has the following specification: =E2=80=A2 OP_ANTI_REPLAY outputs must only be created in a = coinbase transaction. =E2=80=A2 OP_ANTI_REPLAY coinbase outputs must only have the = value of 1 Satoshi. =E2=80=A2 Transaction must not included more than 1 = OP_ANTI_REPLAY input. =E2=80=A2 If a OP_ANTI_REPLAY input is included in a = transaction, the transaction must also be marked as Opt-In-RBF (BIP = 125). The Bitcoin Network should maintain a total of exactly 100 000 = OP_ANTI_REPLAY outputs, with the exception of the the first 99 blocks = after activation of this soft fork. Upon activation of this soft fork. Every blocks coinbase transaction = will be required to create exactly 1000 new OP_ANTI_REPLAY outputs, up = to the total of 100 000. If a OP_ANTI_REPLAY is spent in a block, a corresponding new = OP_ANTI_REPLAY must be included in the same block. It is recommend the miners account the size of a OP_ANTI_REPLAY = transaction as: transactions size + size of a OP_ANTI_REPLAY output in = coinbase. In the case of an chain split after this BIP has activated, miners = should =E2=80=98recycle=E2=80=99 all the OP_ANTI_REPLAY outputs via = spending and recreating them in new blocks. Renewing the protection to = the new chain. =3D=3D=3D Reference implementation =3D=3D=3D To-Be-Implemented =3D=3DBackwards Compatibility=3D=3D This deployment is compatible with all existing bitcoin software. Upon activation, all deployed Bitcoin Full Nodes will enforce the = anti-replay projections for Bitcoin Users. (Only upgraded nodes will = enforce the other OP_ANTI_REPLAY requirements). =3D=3DRationale=3D=3D The only know way of guaranteeing that a transaction cannot be replayed = is to include an input that cannot exist, by-definition, on the = alternative chain. Coinbase transactions are the only transaction type = that is know to exhibit this property strongly. This BIP makes it convenient for wallets to automate the inclusion of = new coinbase inputs into transactions that spend potentially repayable = transactions. Everything in this BIP could be done manually by close = cooperation between the users and miners, however the author thinks that = it is preferable to have it well-defined and enforced. On Opt-In-RBF enforcement: In the case of conflicting spends of = OP_ANTI_REPLAY outputs, the higher-fee transaction should take priority. = Wallets may select a random OP_ANTI_REPLAY, then check if the competing = transaction has a sufficiently low fee to be replaced. It is expected that every OP_ANTI_REPLAY output will be in the memory = pools waiting to be spend; users must compete for this resource. =3D=3DFuture Questions=3D=3D SegWit Compatibility? =3D=3DReferences=3D=3D Opt-In-RBF: = https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki =3D=3DCopyright=3D=3D This document is dual licensed as BSD 3-clause, and Creative Commons CC0 = 1.0 Universal.