đź“… Original date posted:2017-01-26
đź“ť Original message:"A. For users on both existing and new fork, anti-replay is an option,
not mandatory"
To maximize fork divergence, it might make sense to require this. Any
sensible proposal for a hard fork would include a change to the sighash
anyway, so might as well make it required, no?
Matt
On 01/24/17 14:33, Johnson Lau via bitcoin-dev wrote:
> This is a pre-BIP. Just need some formatting to make it a formal BIP
>
> Motivation:
>
> In general, hardforks are consensus rule changes that make currently
> invalid transactions / blocks valid. It requires a very high degree of
> consensus and all economic active users migrate to the new rules at the
> same time. If a significant amount of users refuse to follow, a
> permanent ledger split may happen, as demonstrated by Ethereum (“DAO
> hardfork"). In the design of DAO hardfork, a permanent split was not
> anticipated and no precaution has been taken to protect against
> transaction replay attack, which led to significant financial loss for
> some users.
>
> A replay attack is an attempt to replay a transaction of one network on
> another network. It is normally impossible, for example between Bitcoin
> and Litecoin, as different networks have completely different ledgers.
> The txid as SHA256 hash guarantees that replay across network is
> impossible. In a blockchain split, however, since both forks share the
> same historical ledger, replay attack would be possible, unless some
> precautions are taken.
>
> Unfortunately, fixing problems in bitcoin is like repairing a flying
> plane. Preventing replay attack is constrained by the requirement of
> backward compatibility. This proposal has the following objectives:
>
> A. For users on both existing and new fork, anti-replay is an option,
> not mandatory.
>
> 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.
>
> C. It doesn’t require any consensus changes in the existing network to
> avoid unnecessary debate.
>
> D. As a beneficial side effect, the O(n^2) signature checking bug could
> be fixed for non-segregated witness inputs, optionally.
>
> Definitions:
>
> “Network characteristic byte” is the most significant byte of the
> nVersion field of a transaction. It is interpreted as a bit vector, and
> denotes up to 8 networks sharing a common history.
>
> “Masked version” is the transaction nVersion with the network
> characteristic byte masked.
>
> “Existing network” is the Bitcoin network with existing rules, before a
> hardfork. “New network” is the Bitcoin network with hardfork rules. (In
> the case of DAO hardfork, Ethereum Classic is the existing network, and
> the now called Ethereum is the new network)
>
> “Existing network characteristic bit” is the lowest bit of network
> characteristic byte
>
> “New network characteristic bit” is the second lowest bit of network
> characteristic byte
>
> Rules in new network:
>
> 1. If the network characteristic byte is non-zero, and the new network
> characteristic bit is not set, this transaction is invalid in the new
> network. (softfork)
>
> 2. If the network characteristic byte is zero, go to 4
>
> 3. If the network characteristic byte is non-zero, and the new network
> characteristic bit is set, go to 4, regardless of the status of the
> other bits.
>
> 4. If the masked version is 2 or below, the new network must verify the
> transaction with the existing script rules. (no change)
>
> 5. If the masked version is 3 or above, the new network must verify the
> signatures with a new SignatureHash algorithm (hardfork). Segwit and
> non-segwit txs will use the same algorithm. It is same as BIP143, except
> that 0x2000000 is added to the nHashType before the hash is calculated.
>
> Rules in the existing network:
>
> 6. No consensus rule changes is made in the existing network.
>
> 7. If the network characteristic byte is non-zero, and the existing
> network characteristic bit is not set, this transaction is not relayed
> nor mined by default (no change)
>
> 8. If the network characteristic byte is zero, no change
>
> 9. If the network characteristic byte is non-zero, and the existing
> network characteristic bit is set, the masked version is used to
> determine whether a transaction should be mined or relayed (policy change)
>
> 10. Wallet may provide an option for setting the existing network
> characteristic bit.
>
>
> Rationales (by rule number):
>
> 1. This makes sure transactions with only existing network
> characteristic bit set is invalid in the new network (opt-in anti-replay
> for existing network transactions on the new network, objective A)
>
> 2+4. This makes sure time-locked transactions made before this proposals
> are valid in the new network (objective B)
>
> 2+5. This makes sure transactions made specifically for the new network
> are invalid in the existing network (anti-replay for new network
> transactions on the old network); also fixing the O(n^2) bug (objectives
> A and D)
>
> 3. This is to prepare for the next hardfork from the new network
> (objective A)
>
> 6, 7, 8. These minimise the change to the existing network (objective C)
>
> 9, 10. These are not strictly needed until a hardfork is really
> anticipated. Without a significant portion of the network and miners
> implement this policy, however, no one should create such transactions.
> (objective A)
>
>
> Limitations:
>
> * It is not possible to protect transactions made before the proposal.
> To avoid a replay of such transactions, users should first spend at
> least a relevant UTXO on the new network so the replay transaction would
> be invalidated.
>
> * It is up to the designer of a hardfork to decide whether this proposal
> is respected. As the DAO hardfork has shown how harmful replay attack
> could be, all hardfork proposals (except trivial and totally
> uncontroversial ones) should take this into account
>
> * The size of network characteristic byte is limited to 8 bits. However,
> if we are sure that some of the networks are completely abandoned, the
> bits might be reused.
>
>
> Reference implementation:
>
> A demo is available in my forcenet2
> branch: https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 17:55:39
in reply to nevent1q…4nhg
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 17:55:39Event JSON
{
"id": "3e80a7025d1beb452c68119d4e29f6f37fa4446aaa348299aa4f94e76ac7e892",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686160539,
"kind": 1,
"tags": [
[
"e",
"08564427a86ede87bab23151dbcfb043a11ce80299dd31e312bfe1aa29950657",
"",
"root"
],
[
"e",
"1bcaaf3100660c5caca758b59dfd18f13ba8829cc708d6bbe0680fa697093cd3",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2017-01-26\n📝 Original message:\"A. For users on both existing and new fork, anti-replay is an option,\nnot mandatory\"\n\nTo maximize fork divergence, it might make sense to require this. Any\nsensible proposal for a hard fork would include a change to the sighash\nanyway, so might as well make it required, no?\n\nMatt\n\nOn 01/24/17 14:33, Johnson Lau via bitcoin-dev wrote:\n\u003e This is a pre-BIP. Just need some formatting to make it a formal BIP\n\u003e \n\u003e Motivation:\n\u003e \n\u003e In general, hardforks are consensus rule changes that make currently\n\u003e invalid transactions / blocks valid. It requires a very high degree of\n\u003e consensus and all economic active users migrate to the new rules at the\n\u003e same time. If a significant amount of users refuse to follow, a\n\u003e permanent ledger split may happen, as demonstrated by Ethereum (“DAO\n\u003e hardfork\"). In the design of DAO hardfork, a permanent split was not\n\u003e anticipated and no precaution has been taken to protect against\n\u003e transaction replay attack, which led to significant financial loss for\n\u003e some users.\n\u003e \n\u003e A replay attack is an attempt to replay a transaction of one network on\n\u003e another network. It is normally impossible, for example between Bitcoin\n\u003e and Litecoin, as different networks have completely different ledgers.\n\u003e The txid as SHA256 hash guarantees that replay across network is\n\u003e impossible. In a blockchain split, however, since both forks share the\n\u003e same historical ledger, replay attack would be possible, unless some\n\u003e precautions are taken.\n\u003e \n\u003e Unfortunately, fixing problems in bitcoin is like repairing a flying\n\u003e plane. Preventing replay attack is constrained by the requirement of\n\u003e backward compatibility. This proposal has the following objectives:\n\u003e \n\u003e A. For users on both existing and new fork, anti-replay is an option,\n\u003e not mandatory.\n\u003e \n\u003e B. For transactions created before this proposal is made, they are not\n\u003e protected from anti-replay. The new fork has to accept these\n\u003e transactions, as there is no guarantee that the existing fork would\n\u003e survive nor maintain any value. People made time-locked transactions in\n\u003e anticipation that they would be accepted later. In order to maximise the\n\u003e value of such transactions, the only way is to make them accepted by any\n\u003e potential hardforks.\n\u003e \n\u003e C. It doesn’t require any consensus changes in the existing network to\n\u003e avoid unnecessary debate.\n\u003e \n\u003e D. As a beneficial side effect, the O(n^2) signature checking bug could\n\u003e be fixed for non-segregated witness inputs, optionally.\n\u003e \n\u003e Definitions:\n\u003e \n\u003e “Network characteristic byte” is the most significant byte of the\n\u003e nVersion field of a transaction. It is interpreted as a bit vector, and\n\u003e denotes up to 8 networks sharing a common history.\n\u003e \n\u003e “Masked version” is the transaction nVersion with the network\n\u003e characteristic byte masked.\n\u003e \n\u003e “Existing network” is the Bitcoin network with existing rules, before a\n\u003e hardfork. “New network” is the Bitcoin network with hardfork rules. (In\n\u003e the case of DAO hardfork, Ethereum Classic is the existing network, and\n\u003e the now called Ethereum is the new network)\n\u003e \n\u003e “Existing network characteristic bit” is the lowest bit of network\n\u003e characteristic byte\n\u003e \n\u003e “New network characteristic bit” is the second lowest bit of network\n\u003e characteristic byte\n\u003e \n\u003e Rules in new network:\n\u003e \n\u003e 1. If the network characteristic byte is non-zero, and the new network\n\u003e characteristic bit is not set, this transaction is invalid in the new\n\u003e network. (softfork)\n\u003e \n\u003e 2. If the network characteristic byte is zero, go to 4\n\u003e \n\u003e 3. If the network characteristic byte is non-zero, and the new network\n\u003e characteristic bit is set, go to 4, regardless of the status of the\n\u003e other bits.\n\u003e \n\u003e 4. If the masked version is 2 or below, the new network must verify the\n\u003e transaction with the existing script rules. (no change)\n\u003e \n\u003e 5. If the masked version is 3 or above, the new network must verify the\n\u003e signatures with a new SignatureHash algorithm (hardfork). Segwit and\n\u003e non-segwit txs will use the same algorithm. It is same as BIP143, except\n\u003e that 0x2000000 is added to the nHashType before the hash is calculated.\n\u003e \n\u003e Rules in the existing network:\n\u003e \n\u003e 6. No consensus rule changes is made in the existing network.\n\u003e \n\u003e 7. If the network characteristic byte is non-zero, and the existing\n\u003e network characteristic bit is not set, this transaction is not relayed\n\u003e nor mined by default (no change)\n\u003e \n\u003e 8. If the network characteristic byte is zero, no change\n\u003e \n\u003e 9. If the network characteristic byte is non-zero, and the existing\n\u003e network characteristic bit is set, the masked version is used to\n\u003e determine whether a transaction should be mined or relayed (policy change)\n\u003e \n\u003e 10. Wallet may provide an option for setting the existing network\n\u003e characteristic bit.\n\u003e \n\u003e \n\u003e Rationales (by rule number):\n\u003e \n\u003e 1. This makes sure transactions with only existing network\n\u003e characteristic bit set is invalid in the new network (opt-in anti-replay\n\u003e for existing network transactions on the new network, objective A)\n\u003e \n\u003e 2+4. This makes sure time-locked transactions made before this proposals\n\u003e are valid in the new network (objective B)\n\u003e \n\u003e 2+5. This makes sure transactions made specifically for the new network\n\u003e are invalid in the existing network (anti-replay for new network\n\u003e transactions on the old network); also fixing the O(n^2) bug (objectives\n\u003e A and D)\n\u003e \n\u003e 3. This is to prepare for the next hardfork from the new network\n\u003e (objective A)\n\u003e \n\u003e 6, 7, 8. These minimise the change to the existing network (objective C)\n\u003e \n\u003e 9, 10. These are not strictly needed until a hardfork is really\n\u003e anticipated. Without a significant portion of the network and miners\n\u003e implement this policy, however, no one should create such transactions.\n\u003e (objective A)\n\u003e \n\u003e \n\u003e Limitations:\n\u003e \n\u003e * It is not possible to protect transactions made before the proposal.\n\u003e To avoid a replay of such transactions, users should first spend at\n\u003e least a relevant UTXO on the new network so the replay transaction would\n\u003e be invalidated.\n\u003e \n\u003e * It is up to the designer of a hardfork to decide whether this proposal\n\u003e is respected. As the DAO hardfork has shown how harmful replay attack\n\u003e could be, all hardfork proposals (except trivial and totally\n\u003e uncontroversial ones) should take this into account\n\u003e \n\u003e * The size of network characteristic byte is limited to 8 bits. However,\n\u003e if we are sure that some of the networks are completely abandoned, the\n\u003e bits might be reused.\n\u003e \n\u003e \n\u003e Reference implementation:\n\u003e \n\u003e A demo is available in my forcenet2\n\u003e branch: https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html\n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "29cd9411144997168fc0e295048687f736b521c73f0368866a6b81869d62decd1474bd95a494a53d3f70849d358e16e1512a1644fc200b1bc0d67e1536e4d1bc"
}