From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Cameron Garnham <da2ce7@gmail.com>
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>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201703290915.58724.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Strong Anti-Replay via Coinbase Transactions
Precedence: list

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