What you describe is not a fix of replay attack. By confirming the same tx in both network, the tx has been already replayed. Their child txs do not matter.
> On 25 Jan 2017, at 09:22, Natanael <natanae...@gmail.com> wrote: > > > > Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>>: > > > B. For transactions created before this proposal is made, they are not > protected from anti-replay. The new fork has to accept these transactions, as > there is no guarantee that the existing fork would survive nor maintain any > value. People made time-locked transactions in anticipation that they would > be accepted later. In order to maximise the value of such transactions, the > only way is to make them accepted by any potential hardforks. > > This can be fixed. > > Make old-format transactions valid *only when paired with a fork-only > follow-up transaction* which is spending at least one (or all) of the outputs > of the old-format transaction. > > (Yes, I know this introduces new statefulness into the block validation > logic. Unfortunately it is necessary for maximal fork safety. It can be > disabled at a later time if ever deemed no longer necessary.) > > Meanwhile, the old network SHOULD soft-fork in an identical rule with a > follow-up transaction format incompatible with the fork. > > This means that old transactions can not be replayed across forks/networks, > because they're not valid when stand-alone. It also means that all wallet > clients either needs to be updated OR paired with software that intercepts > generated transactions, and automatically generates the correct follow-up > transaction for it (old network only). > > The rules should be that old-format transactions can't reference new-format > transactions, even if only a softfork change differ between the formats. This > prevents an unnecessary amount of transactions pairs generated by old > wallets. Thus they can spend old outputs, but not spend new ones. > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
