Discussion:
Strong Anti-Replay via Coinbase Transactions
(too old to reply)
Cameron Garnham via bitcoin-dev
2017-03-25 03:30:22 UTC
Permalink
Raw Message
<pre>
BIP: ???
Layer: Consensus (soft fork)
Title: Strong Anti-Replay via Coinbase Transactions
Author: Cameron Garnham <***@gmail.com>
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
</pre>

==Abstract==

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.

==Definitions==



==Motivation==

In the case of a chain split, it is important to protect users from, potentially significant, loss of funds from transaction replay attacks.


==Specification==

Upon activation of the soft-fork (activation methodology undefined in this proposal), the following new rules become activated on the Bitcoin Network.

New ‘anti-replay’ OpCode. Take an unused NoOp and redefine it as ‘OP_ANTI_REPLAY’.

The script must only have the form:

scriptPubKey: (empty)
scriptSig: OP_ANTI_REPLAY

OP_ANTI_REPLAY has the following specification:

• OP_ANTI_REPLAY outputs must only be created in a coinbase transaction.
• OP_ANTI_REPLAY coinbase outputs must only have the value of 1 Satoshi.
• Transaction must not included more than 1 OP_ANTI_REPLAY input.
• 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 ‘recycle’ all the OP_ANTI_REPLAY outputs via spending and recreating them in new blocks. Renewing the protection to the new chain.


=== Reference implementation ===

To-Be-Implemented

==Backwards Compatibility==

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).

==Rationale==

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.

==Future Questions==

SegWit Compatibility?

==References==

Opt-In-RBF: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
Luke Dashjr via bitcoin-dev
2017-03-29 09:15:57 UTC
Permalink
Raw Message
Post by Cameron Garnham via bitcoin-dev
==Definitions==
It's blank?
Post by Cameron Garnham via bitcoin-dev
==Specification==
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.
Post by Cameron Garnham via bitcoin-dev
New ‘anti-replay’ OpCode. Take an unused NoOp and redefine it as ‘OP_ANTI_REPLAY’.
Need to be specific about which NOP.
Post by Cameron Garnham via bitcoin-dev
scriptPubKey: (empty)
scriptSig: OP_ANTI_REPLAY
• OP_ANTI_REPLAY outputs must only be created in a coinbase transaction.
This is contradicting. scriptSig is not part of an output. Did you get the two
scripts inverted?
Post by Cameron Garnham via bitcoin-dev
• OP_ANTI_REPLAY coinbase outputs must only have the value of 1 Satoshi.
Why burn a satoshi?
Post by Cameron Garnham via bitcoin-dev
• Transaction must not included more than 1 OP_ANTI_REPLAY input.
include*
Post by Cameron Garnham via bitcoin-dev
• If a OP_ANTI_REPLAY input is included in a transaction, the transaction
must also be marked as Opt-In-RBF (BIP 125).
This is a layering violation. BIP 125 does not affect the consensus rules.
Post by Cameron Garnham via bitcoin-dev
In the case of an chain split after this BIP has activated, miners should
‘recycle’ 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 are
limited to one each.

Chain splits also happen regularly (probably at least once or twice every few
hundred blocks). Since generated UTXOs cannot be spent for 100 blocks, it is
likely anything using this would require constant updating.

It also requires active awareness from the miner that a split is occurring.
Usually, this is not known until the block is solved, and it is too late to
make these recycling transactions.
Post by Cameron Garnham via bitcoin-dev
=== Reference implementation ===
To-Be-Implemented
I don't think it's possible to implement for the reasons mentioned above.
Post by Cameron Garnham via bitcoin-dev
==Rationale==
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 proposed
OP_CHECKBLOCKATHEIGHT.
Post by Cameron Garnham via bitcoin-dev
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.
This isn't convenient. Most wallets have no reasonable way to check if there
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 the
transactions? This can be done so long as the signature doesn't commit to the
recycle input. So for each transaction, there would be an input with the last-
recycle-txid (tracked by the miner as it builds the block), and an output
generating the next-recycle-txid. Wallets could just indicate this input to be
used by providing a special hash as the input which is not covered under the
signature.
Post by Cameron Garnham via bitcoin-dev
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.
UTXO set, not memory pool?

Luke

Loading...