Re: [bitcoin-dev] Strong Anti-Replay via Coinbase Transactions

[Luke Dashjr <luke@dashjr.org>]

On Saturday, March 25, 2017 3:30:22 AM Cameron Garnham via bitcoin-dev wrote:
> ==Definitions==

It's blank?

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

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

Need to be specific about which NOP.

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

This is contradicting. scriptSig is not part of an output. Did you get the two 
scripts inverted?

> 	• OP_ANTI_REPLAY coinbase outputs must only have the value of 1 Satoshi.

Why burn a satoshi?

> 	• Transaction must not included more than 1 OP_ANTI_REPLAY input.

include*

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

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

> === Reference implementation ===
> 
> To-Be-Implemented

I don't think it's possible to implement for the reasons mentioned above.

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

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

> 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