📅 Original date posted:2017-01-25
📝 Original message: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 <natanael.l at gmail.com> wrote:
>
>
>
> Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170125/7ef54e56/attachment.html>;
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 17:55:38
in reply to nevent1q…p8xg
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 17:55:38Event JSON
{
"id": "a67193f954236ac59950e1b306d0ecdfe110b5e77995320a7c3cc6cb24df7d55",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686160538,
"kind": 1,
"tags": [
[
"e",
"08564427a86ede87bab23151dbcfb043a11ce80299dd31e312bfe1aa29950657",
"",
"root"
],
[
"e",
"778d98b6d7ca0cf19e38076b857743a3ee60ea619ef8b2808061ecd2e4db8c47",
"",
"reply"
],
[
"p",
"f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018"
]
],
"content": "📅 Original date posted:2017-01-25\n📝 Original message: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.\n\n\u003e On 25 Jan 2017, at 09:22, Natanael \u003cnatanael.l at gmail.com\u003e wrote:\n\u003e \n\u003e \n\u003e \n\u003e Den 24 jan. 2017 15:33 skrev \"Johnson Lau via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e:\n\u003e \n\u003e \n\u003e 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.\n\u003e \n\u003e This can be fixed. \n\u003e \n\u003e 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. \n\u003e \n\u003e (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.)\n\u003e \n\u003e Meanwhile, the old network SHOULD soft-fork in an identical rule with a follow-up transaction format incompatible with the fork. \n\u003e \n\u003e 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). \n\u003e \n\u003e 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. \n\u003e \n\u003e \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170125/7ef54e56/attachment.html\u003e",
"sig": "6805fc94006be7adfb8e7ca51699e0b8fcde5a182e44e05d92575d2f545539c3f82e933fb5c48b6e0fe7b8ccb1229f28a0cbfd279684cf73040597410708bfc0"
}