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 34E808D4 for ; Wed, 29 Mar 2017 09:16:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 99B11166 for ; Wed, 29 Mar 2017 09:16:16 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id C1B6538ABEDA; Wed, 29 Mar 2017 09:15:59 +0000 (UTC) X-Hashcash: 1:25:170329:bitcoin-dev@lists.linuxfoundation.org::G4R/OD+ad=mAZeAH:5pNr X-Hashcash: 1:25:170329:da2ce7@gmail.com::8yxUdR5ac7=EdsJo:aQ356 From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Cameron Garnham Date: Wed, 29 Mar 2017 09:15:57 +0000 User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; ) References: <07F54C7C-5F26-446D-A479-7F81BD131151@gmail.com> In-Reply-To: <07F54C7C-5F26-446D-A479-7F81BD131151@gmail.com> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201703290915.58724.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [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: Wed, 29 Mar 2017 09:16:17 -0000 On Saturday, March 25, 2017 3:30:22 AM Cameron Garnham via bitcoin-dev wrot= e: > =3D=3DDefinitions=3D=3D It's blank? > =3D=3DSpecification=3D=3D >=20 > Upon activation of the soft-fork (activation methodology undefined in this > proposal), the following new rules become activated on the Bitcoin > Network. The activation methodology should be defined. It can be a TODO for now. > New =E2=80=98anti-replay=E2=80=99 OpCode. Take an unused NoOp and redefi= ne it as > =E2=80=98OP_ANTI_REPLAY=E2=80=99. Need to be specific about which NOP. > The script must only have the form: >=20 > scriptPubKey: (empty) > scriptSig: OP_ANTI_REPLAY >=20 > OP_ANTI_REPLAY has the following specification: >=20 > =E2=80=A2 OP_ANTI_REPLAY outputs must only be created in a coinbase tran= saction. This is contradicting. scriptSig is not part of an output. Did you get the = two=20 scripts inverted? > =E2=80=A2 OP_ANTI_REPLAY coinbase outputs must only have the value of 1 = Satoshi. Why burn a satoshi? > =E2=80=A2 Transaction must not included more than 1 OP_ANTI_REPLAY input. include* > =E2=80=A2 If a OP_ANTI_REPLAY input is included in a transaction, the tr= ansaction > must also be marked as Opt-In-RBF (BIP 125). This is a layering violation. BIP 125 does not affect the consensus rules. > 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. *a* chain split This recycling is going to be pretty spammy... especially if transactions a= re=20 limited to one each. Chain splits also happen regularly (probably at least once or twice every f= ew =20 hundred blocks). Since generated UTXOs cannot be spent for 100 blocks, it i= s=20 likely anything using this would require constant updating. It also requires active awareness from the miner that a split is occurring.= =20 Usually, this is not known until the block is solved, and it is too late to= =20 make these recycling transactions. > =3D=3D=3D Reference implementation =3D=3D=3D >=20 > To-Be-Implemented I don't think it's possible to implement for the reasons mentioned above. > =3D=3DRationale=3D=3D >=20 > 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. known* Another way is to commit to a specific chain explicitly, as with my propose= d=20 OP_CHECKBLOCKATHEIGHT. > 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. >=20 > On Opt-In-RBF enforcement: In the case of conflicting spends of > OP_ANTI_REPLAY outputs, the higher-fee transaction should take priority.= =20 > Wallets may select a random OP_ANTI_REPLAY, then check if the competing > transaction has a sufficiently low fee to be replaced. This isn't convenient. Most wallets have no reasonable way to check if ther= e=20 are any competing transactions, much less what the fee for them is. Why not just use a single reserved output, and have it recycle as part of t= he=20 transactions? This can be done so long as the signature doesn't commit to t= he=20 recycle input. So for each transaction, there would be an input with the la= st- recycle-txid (tracked by the miner as it builds the block), and an output=20 generating the next-recycle-txid. Wallets could just indicate this input to= be=20 used by providing a special hash as the input which is not covered under th= e=20 signature. > It is expected that every OP_ANTI_REPLAY output will be in the memory poo= ls > waiting to be spend; users must compete for this resource. UTXO set, not memory pool? Luke