* [bitcoin-dev] Anti-transaction replay in a hardfork
@ 2017-01-24 14:33 Johnson Lau
2017-01-24 18:52 ` Tom Harding
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Johnson Lau @ 2017-01-24 14:33 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 6335 bytes --]
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://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html>
[-- Attachment #2: Type: text/html, Size: 8669 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-24 14:33 [bitcoin-dev] Anti-transaction replay in a hardfork Johnson Lau
@ 2017-01-24 18:52 ` Tom Harding
2017-01-25 4:03 ` Johnson Lau
2017-01-25 1:22 ` Natanael
2017-01-26 3:29 ` Matt Corallo
2 siblings, 1 reply; 21+ messages in thread
From: Tom Harding @ 2017-01-24 18:52 UTC (permalink / raw)
To: bitcoin-dev, Johnson Lau
On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
> 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)
Johnson,
Your proposal supports 8 opt-out bits compatible with may earlier
description:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.
If the existing network really wants to play along, it should execute a
soft fork as soon as possible to support its own hard-fork opt-out bit
("network characteristic bit"). It is totally inadequate for a new
network to rely on non-standardness in the existing network to prevent
replay there. Instead, in the absence of a supported opt-out bit in the
existing network, a responsible new network would allow something that
is invalid in the existing network, for transactions where replay to the
existing network is undesirable.
It is an overreach for your BIP to suggest specific changes to be
included in the new network, such as the specific O(n^2) fix you
suggest. This is a matter for the new network itself.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-24 14:33 [bitcoin-dev] Anti-transaction replay in a hardfork Johnson Lau
2017-01-24 18:52 ` Tom Harding
@ 2017-01-25 1:22 ` Natanael
2017-01-25 7:05 ` Johnson Lau
2017-01-26 3:29 ` Matt Corallo
2 siblings, 1 reply; 21+ messages in thread
From: Natanael @ 2017-01-25 1:22 UTC (permalink / raw)
To: Bitcoin Dev, Johnson Lau
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <
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.
[-- Attachment #2: Type: text/html, Size: 2509 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-24 18:52 ` Tom Harding
@ 2017-01-25 4:03 ` Johnson Lau
2017-01-25 19:32 ` Tom Harding
0 siblings, 1 reply; 21+ messages in thread
From: Johnson Lau @ 2017-01-25 4:03 UTC (permalink / raw)
To: Tom Harding, bitcoin-dev
Yes, it’s similar. I’ll quote your design if/when I formalise my BIP. But it seems they are not the same: yours is opt-out, while mine is opt-in.
However, my proposal in nowhere depends on standardness for the protection. It depends on the new network enforcing a new SignatureHash for txs with an nVersion not used in the existing network. This itself is a hardfork and the existing network would never accept such txs.
This is to avoid requiring any consensus changes to the existing network, as there is no guarantee that such softfork would be accepted by the existing network. If the new network wants to protect their users, it’d be trivial for them to include a SignatureHash hardfork like this, along with other other hardfork changes. Further hardforks will only require changing the network characteristic bit, but not the SignatureHash.
If the hardfork designers don’t like the fix of BIP143, there are many other options. The simplest one would be a trivial change to Satoshi’s SignatureHash, such as adding an extra value at the end of the algorithm. I just don’t see any technical reasons not to fix the O(n^2) problem altogether, if it is trivial (but not that trivial if the hardfork is not based on segwit)
> On 25 Jan 2017, at 02:52, Tom Harding <tomh@thinlink•com> wrote:
>
> On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
>> 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)
>
> Johnson,
>
> Your proposal supports 8 opt-out bits compatible with may earlier
> description:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.
>
> If the existing network really wants to play along, it should execute a
> soft fork as soon as possible to support its own hard-fork opt-out bit
> ("network characteristic bit"). It is totally inadequate for a new
> network to rely on non-standardness in the existing network to prevent
> replay there. Instead, in the absence of a supported opt-out bit in the
> existing network, a responsible new network would allow something that
> is invalid in the existing network, for transactions where replay to the
> existing network is undesirable.
>
> It is an overreach for your BIP to suggest specific changes to be
> included in the new network, such as the specific O(n^2) fix you
> suggest. This is a matter for the new network itself.
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-25 1:22 ` Natanael
@ 2017-01-25 7:05 ` Johnson Lau
2017-01-25 7:15 ` Natanael
0 siblings, 1 reply; 21+ messages in thread
From: Johnson Lau @ 2017-01-25 7:05 UTC (permalink / raw)
To: Natanael; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
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@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.
>
>
[-- Attachment #2: Type: text/html, Size: 3497 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-25 7:05 ` Johnson Lau
@ 2017-01-25 7:15 ` Natanael
2017-01-25 7:21 ` Johnson Lau
0 siblings, 1 reply; 21+ messages in thread
From: Natanael @ 2017-01-25 7:15 UTC (permalink / raw)
To: Johnson Lau; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
Den 25 jan. 2017 08:06 skrev "Johnson Lau" <jl2012@xbt•hk>:
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.
Read it again.
The validation algorithm would be extended so that the transaction can't be
replayed, because replaying it in the other network REQUIRES a child
transaction in the same block that is valid, a child transaction the is
unique to the network. By doing this policy change simultaneously in both
networks, old pre-signed transactions *can not be replayed by anybody but
the owner* of the coins (as he must spend them immediately in the child
transaction).
It means that as soon as spent, the UTXO sets immediately and irrevocably
diverges across the two networks. Which is the entire point, isn't it?
[-- Attachment #2: Type: text/html, Size: 1358 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-25 7:15 ` Natanael
@ 2017-01-25 7:21 ` Johnson Lau
2017-01-25 7:29 ` Natanael
0 siblings, 1 reply; 21+ messages in thread
From: Johnson Lau @ 2017-01-25 7:21 UTC (permalink / raw)
To: Natanael; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
Assuming Alice is paying Bob with an old style time-locked tx. Under your proposal, after the hardfork, Bob is still able to confirm the time-locked tx on both networks. To fulfil your new rules he just needs to send the outputs to himself again (with different tx format). But as Bob gets all the money on both forks, it is already a successful replay
> On 25 Jan 2017, at 15:15, Natanael <natanael.l@gmail•com> wrote:
>
>
> Den 25 jan. 2017 08:06 skrev "Johnson Lau" <jl2012@xbt•hk <mailto:jl2012@xbt•hk>>:
> 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.
>
> Read it again.
>
> The validation algorithm would be extended so that the transaction can't be replayed, because replaying it in the other network REQUIRES a child transaction in the same block that is valid, a child transaction the is unique to the network. By doing this policy change simultaneously in both networks, old pre-signed transactions *can not be replayed by anybody but the owner* of the coins (as he must spend them immediately in the child transaction).
>
> It means that as soon as spent, the UTXO sets immediately and irrevocably diverges across the two networks. Which is the entire point, isn't it?
[-- Attachment #2: Type: text/html, Size: 2387 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-25 7:21 ` Johnson Lau
@ 2017-01-25 7:29 ` Natanael
2017-01-25 7:42 ` Johnson Lau
0 siblings, 1 reply; 21+ messages in thread
From: Natanael @ 2017-01-25 7:29 UTC (permalink / raw)
To: Johnson Lau; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Den 25 jan. 2017 08:22 skrev "Johnson Lau" <jl2012@xbt•hk>:
Assuming Alice is paying Bob with an old style time-locked tx. Under your
proposal, after the hardfork, Bob is still able to confirm the time-locked
tx on both networks. To fulfil your new rules he just needs to send the
outputs to himself again (with different tx format). But as Bob gets all
the money on both forks, it is already a successful replay
Why would Alice be sitting on an old-style signed transaction with UTXO:s
none of which she controls (paying somebody else), with NO ability to
substitute the transaction for one where she DOES control an output,
leaving her unable to be the one spending the replay protecting child
transaction?
[-- Attachment #2: Type: text/html, Size: 1188 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-25 7:29 ` Natanael
@ 2017-01-25 7:42 ` Johnson Lau
0 siblings, 0 replies; 21+ messages in thread
From: Johnson Lau @ 2017-01-25 7:42 UTC (permalink / raw)
To: Natanael; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]
> On 25 Jan 2017, at 15:29, Natanael <natanael.l@gmail•com> wrote:
>
>
> Den 25 jan. 2017 08:22 skrev "Johnson Lau" <jl2012@xbt•hk <mailto:jl2012@xbt•hk>>:
> Assuming Alice is paying Bob with an old style time-locked tx. Under your proposal, after the hardfork, Bob is still able to confirm the time-locked tx on both networks. To fulfil your new rules he just needs to send the outputs to himself again (with different tx format). But as Bob gets all the money on both forks, it is already a successful replay
>
> Why would Alice be sitting on an old-style signed transaction with UTXO:s none of which she controls (paying somebody else), with NO ability to substitute the transaction for one where she DOES control an output, leaving her unable to be the one spending the replay protecting child transaction?
If Alice still has full control, she is already protected by my proposal, which does not require any protecting child transaction.
But in many cases she may not have full control. Make it clearer, consider that’s actually a 2-of-2 multisig of Alice and Bob, and the time locked tx is sending to Bob. If the time locked tx is unprotected in the first place, Bob will get all the money from both forks anyway, as there is no reason for him to renegotiate with Alice.
[-- Attachment #2: Type: text/html, Size: 2322 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-25 4:03 ` Johnson Lau
@ 2017-01-25 19:32 ` Tom Harding
2017-01-27 20:47 ` Johnson Lau
0 siblings, 1 reply; 21+ messages in thread
From: Tom Harding @ 2017-01-25 19:32 UTC (permalink / raw)
To: Johnson Lau, bitcoin-dev
On 1/24/2017 8:03 PM, Johnson Lau wrote:
> it seems they are not the same: yours is opt-out, while mine is opt-in.
I missed this. So in fact you propose a self-defeating requirement on
the new network, which would force unmodified yet otherwise compatible
systems to change to support the new network at all. This is unlikely to
be included in new network designs.
I suggest that the opt-out bits proposal comes from a more realistic
position that would actually make sense for everyone.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-24 14:33 [bitcoin-dev] Anti-transaction replay in a hardfork Johnson Lau
2017-01-24 18:52 ` Tom Harding
2017-01-25 1:22 ` Natanael
@ 2017-01-26 3:29 ` Matt Corallo
2017-01-26 7:03 ` Chris Priest
2017-01-26 17:21 ` Gavin Andresen
2 siblings, 2 replies; 21+ messages in thread
From: Matt Corallo @ 2017-01-26 3:29 UTC (permalink / raw)
To: Johnson Lau, Bitcoin Protocol Discussion
"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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 3:29 ` Matt Corallo
@ 2017-01-26 7:03 ` Chris Priest
2017-01-26 7:14 ` Johnson Lau
2017-01-26 17:21 ` Gavin Andresen
1 sibling, 1 reply; 21+ messages in thread
From: Chris Priest @ 2017-01-26 7:03 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
I don't think the solution should be to "fix the replay attack", but
rather to "force the replay effect". The fact that transactions can be
relayed should be seen as a good thing, and not something that should
be fixed, or even called an "attack".
The solution should be to create a "bridge" that replays all
transactions from one network over to the other, and vice-versa. A
fork should be transparent to the end-user. Forcing the user to choose
which network to use is bad, because 99% of people that use bitcoin
don't care about developer drama, and will only be confused by the
choice. When a user moves coins mined before the fork date, both
blockchains should record that transaction. Also a rule should be
introduced that prevents users "tainting" their prefork-mined coins
with coins mined after the fork. All pre-fork mined coins should
"belong" to the network with hashpower majority. No other networks
should be able to claim pre-forked coins as being part of their
issuance (and therefore part of market cap). Market cap may be
bullshit, but it is used a lot in the cryptosphere to compare coins to
each other.
The advantage of pre-fork coins being recorded on both forks is that
if one fork goes extinct, no one loses any money. This setup
encourages the minority chain to die,and unity returned. If pre-fork
coins change hands on either fork (and not on the other), then holders
have an incentive to not let their chain die, and the networks will be
irreversibly split forever. The goal should be unity not permanent
division.
On 1/25/17, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> "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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 7:03 ` Chris Priest
@ 2017-01-26 7:14 ` Johnson Lau
2017-01-26 8:59 ` Chris Priest
0 siblings, 1 reply; 21+ messages in thread
From: Johnson Lau @ 2017-01-26 7:14 UTC (permalink / raw)
To: Chris Priest; +Cc: bitcoin-dev
I don’t think this is how the blockchain consensus works. If there is a split, it becomes 2 incompatible ledgers. Bitcoin is not a trademark, and you don’t need a permission to hardfork it. And what you suggest is also technically infeasible, as the miners on the new chain may not have a consensus only what’s happening in the old chain.
> On 26 Jan 2017, at 15:03, Chris Priest <cp368202@ohiou•edu> wrote:
>
> I don't think the solution should be to "fix the replay attack", but
> rather to "force the replay effect". The fact that transactions can be
> relayed should be seen as a good thing, and not something that should
> be fixed, or even called an "attack".
>
> The solution should be to create a "bridge" that replays all
> transactions from one network over to the other, and vice-versa. A
> fork should be transparent to the end-user. Forcing the user to choose
> which network to use is bad, because 99% of people that use bitcoin
> don't care about developer drama, and will only be confused by the
> choice. When a user moves coins mined before the fork date, both
> blockchains should record that transaction. Also a rule should be
> introduced that prevents users "tainting" their prefork-mined coins
> with coins mined after the fork. All pre-fork mined coins should
> "belong" to the network with hashpower majority. No other networks
> should be able to claim pre-forked coins as being part of their
> issuance (and therefore part of market cap). Market cap may be
> bullshit, but it is used a lot in the cryptosphere to compare coins to
> each other.
>
> The advantage of pre-fork coins being recorded on both forks is that
> if one fork goes extinct, no one loses any money. This setup
> encourages the minority chain to die,and unity returned. If pre-fork
> coins change hands on either fork (and not on the other), then holders
> have an incentive to not let their chain die, and the networks will be
> irreversibly split forever. The goal should be unity not permanent
> division.
>
> On 1/25/17, Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> "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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 7:14 ` Johnson Lau
@ 2017-01-26 8:59 ` Chris Priest
2017-01-26 9:20 ` Johnson Lau
0 siblings, 1 reply; 21+ messages in thread
From: Chris Priest @ 2017-01-26 8:59 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
> If there is a split, it becomes 2 incompatible ledgers.
Not necessarily. When the BIP50 hard fork happened, it didn't create
two incompatible ledgers. It *could* have, but it didn't. If every
single transaction mined during that time has been "double spent" on
the other chain, then it would have created a very bad situation. When
one side of the fork gets abandoned, actual users would have lost
money. Since only one person was able to perform this double spend,
only the miners and that one double spender lost money when the one
side was abandoned. If there had been a significant number of users
who had value only on the chain that was eventually abandoned, that
chain would have incentive to not be abandoned and that *would* have
resulted in a permanent incompatible split. It was essentially the
replay *effect* (not "attack") that allowed bitcoin to survive that
hard fork. BIP50 was written before the term "replay attack" or
"replay effect" has been coined, so it doesn't say much about how
transactions replayed...
On 1/25/17, Johnson Lau <jl2012@xbt•hk> wrote:
> I don’t think this is how the blockchain consensus works. If there is a
> split, it becomes 2 incompatible ledgers. Bitcoin is not a trademark, and
> you don’t need a permission to hardfork it. And what you suggest is also
> technically infeasible, as the miners on the new chain may not have a
> consensus only what’s happening in the old chain.
>
>> On 26 Jan 2017, at 15:03, Chris Priest <cp368202@ohiou•edu> wrote:
>>
>> I don't think the solution should be to "fix the replay attack", but
>> rather to "force the replay effect". The fact that transactions can be
>> relayed should be seen as a good thing, and not something that should
>> be fixed, or even called an "attack".
>>
>> The solution should be to create a "bridge" that replays all
>> transactions from one network over to the other, and vice-versa. A
>> fork should be transparent to the end-user. Forcing the user to choose
>> which network to use is bad, because 99% of people that use bitcoin
>> don't care about developer drama, and will only be confused by the
>> choice. When a user moves coins mined before the fork date, both
>> blockchains should record that transaction. Also a rule should be
>> introduced that prevents users "tainting" their prefork-mined coins
>> with coins mined after the fork. All pre-fork mined coins should
>> "belong" to the network with hashpower majority. No other networks
>> should be able to claim pre-forked coins as being part of their
>> issuance (and therefore part of market cap). Market cap may be
>> bullshit, but it is used a lot in the cryptosphere to compare coins to
>> each other.
>>
>> The advantage of pre-fork coins being recorded on both forks is that
>> if one fork goes extinct, no one loses any money. This setup
>> encourages the minority chain to die,and unity returned. If pre-fork
>> coins change hands on either fork (and not on the other), then holders
>> have an incentive to not let their chain die, and the networks will be
>> irreversibly split forever. The goal should be unity not permanent
>> division.
>>
>> On 1/25/17, Matt Corallo via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> "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@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 8:59 ` Chris Priest
@ 2017-01-26 9:20 ` Johnson Lau
2017-01-26 10:55 ` Edmund Edgar
2017-01-26 15:58 ` Tom Harding
0 siblings, 2 replies; 21+ messages in thread
From: Johnson Lau @ 2017-01-26 9:20 UTC (permalink / raw)
To: Chris Priest; +Cc: bitcoin-dev
BIP50 was an accident, and my proposal is just for a planned hardfork. You can’t anti-replay if you don’t even know a hardfork might happen. And I think your hypothesis (replay reduces the incentive of split) is not supported by the ETC/ETH split.
Aside the philosophical argument, your proposal is not technically feasible. In my understanding, you require the new chain to replay all the txs in the old chain. But this is not possible because there could be orphaning in the old chain, and different miners of the new chain may see a different history of the old chain. Not to mention that mining is a random process, and the hashing power is going up and down. Just by chance, 10 blocks might be generated in the old chain while no block is generated in the new chain. This is also unfair to the new chain miners, as they may not satisfied with the fees paid while they are forced to include those txs from the old chain (remember that people may just pay the old chain miners out of band, and pay no fee in the transaction)
I don’t think these technical issues are solvable when both forks are decentralised mining. If time machines, for example, are not technically feasible, there is not much point to talk about the benefits of time machines.
> On 26 Jan 2017, at 16:59, Chris Priest <cp368202@ohiou•edu> wrote:
>
>> If there is a split, it becomes 2 incompatible ledgers.
>
> Not necessarily. When the BIP50 hard fork happened, it didn't create
> two incompatible ledgers. It *could* have, but it didn't. If every
> single transaction mined during that time has been "double spent" on
> the other chain, then it would have created a very bad situation. When
> one side of the fork gets abandoned, actual users would have lost
> money. Since only one person was able to perform this double spend,
> only the miners and that one double spender lost money when the one
> side was abandoned. If there had been a significant number of users
> who had value only on the chain that was eventually abandoned, that
> chain would have incentive to not be abandoned and that *would* have
> resulted in a permanent incompatible split. It was essentially the
> replay *effect* (not "attack") that allowed bitcoin to survive that
> hard fork. BIP50 was written before the term "replay attack" or
> "replay effect" has been coined, so it doesn't say much about how
> transactions replayed...
>
> On 1/25/17, Johnson Lau <jl2012@xbt•hk> wrote:
>> I don’t think this is how the blockchain consensus works. If there is a
>> split, it becomes 2 incompatible ledgers. Bitcoin is not a trademark, and
>> you don’t need a permission to hardfork it. And what you suggest is also
>> technically infeasible, as the miners on the new chain may not have a
>> consensus only what’s happening in the old chain.
>>
>>> On 26 Jan 2017, at 15:03, Chris Priest <cp368202@ohiou•edu> wrote:
>>>
>>> I don't think the solution should be to "fix the replay attack", but
>>> rather to "force the replay effect". The fact that transactions can be
>>> relayed should be seen as a good thing, and not something that should
>>> be fixed, or even called an "attack".
>>>
>>> The solution should be to create a "bridge" that replays all
>>> transactions from one network over to the other, and vice-versa. A
>>> fork should be transparent to the end-user. Forcing the user to choose
>>> which network to use is bad, because 99% of people that use bitcoin
>>> don't care about developer drama, and will only be confused by the
>>> choice. When a user moves coins mined before the fork date, both
>>> blockchains should record that transaction. Also a rule should be
>>> introduced that prevents users "tainting" their prefork-mined coins
>>> with coins mined after the fork. All pre-fork mined coins should
>>> "belong" to the network with hashpower majority. No other networks
>>> should be able to claim pre-forked coins as being part of their
>>> issuance (and therefore part of market cap). Market cap may be
>>> bullshit, but it is used a lot in the cryptosphere to compare coins to
>>> each other.
>>>
>>> The advantage of pre-fork coins being recorded on both forks is that
>>> if one fork goes extinct, no one loses any money. This setup
>>> encourages the minority chain to die,and unity returned. If pre-fork
>>> coins change hands on either fork (and not on the other), then holders
>>> have an incentive to not let their chain die, and the networks will be
>>> irreversibly split forever. The goal should be unity not permanent
>>> division.
>>>
>>> On 1/25/17, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>> "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@lists•linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>
>>
>>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 9:20 ` Johnson Lau
@ 2017-01-26 10:55 ` Edmund Edgar
2017-01-26 15:58 ` Tom Harding
1 sibling, 0 replies; 21+ messages in thread
From: Edmund Edgar @ 2017-01-26 10:55 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
On 26 January 2017 at 18:20, Johnson Lau via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>You can’t anti-replay if you don’t even know a hardfork might happen. And I think your hypothesis (replay reduces the incentive of split) is not supported by the ETC/ETH split.
I agree with the general point you're making, but you *could*
anti-replay without knowing about the fork, at least from a few dozen
blocks into it. For example you could allow transactions to specify a
recent block hash (or some of the bytes thereof) and declare that they
want to be invalid if that block isn't in the parent chain.
This would potentially have benefits beyond economic hard-fork
situations: As a general principle, if the network that you're
transacting with doesn't look like the one you think you're
transacting with, you're going to have a bad day.
--
--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp
Reality Keys
@realitykeys
ed@realitykeys•com
https://www.realitykeys.com
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 9:20 ` Johnson Lau
2017-01-26 10:55 ` Edmund Edgar
@ 2017-01-26 15:58 ` Tom Harding
1 sibling, 0 replies; 21+ messages in thread
From: Tom Harding @ 2017-01-26 15:58 UTC (permalink / raw)
To: bitcoin-dev
Even more to the point, new post- fork coins are fork-specific. The
longer both forks persist, the more transactions become unavoidably
fork-specific through the mixing in of these coins. Any attempt to
maximize replay will become less effective with time.
The rationality of actors in this situation essentially defines the
limited solution that is possible. Upgraded software can create
transactions guaranteed not to execute to one fork or the other, or that
is not prevented from execution on either fork. I see no downside to
this, and the advantage is that markets can be much less chaotic. In
fact exchanges will be much better off if they require that post-fork
trading, deposits and withdrawals are exclusively chain-specific, which
will also result in well determined prices for the two currencies.
None of this precludes the possibility of further forks on either side,
and the difficulty consideration alone suggests a likely counter-fork by
(part of) the existing network.
On 1/26/2017 1:20 AM, Johnson Lau via bitcoin-dev wrote:
> Not to mention that mining is a random process, and the hashing power is going up and down.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 3:29 ` Matt Corallo
2017-01-26 7:03 ` Chris Priest
@ 2017-01-26 17:21 ` Gavin Andresen
2017-01-26 17:41 ` Matt Corallo
1 sibling, 1 reply; 21+ messages in thread
From: Gavin Andresen @ 2017-01-26 17:21 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
On Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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?
>
Compatibility with existing transaction-signing software and hardware
should be considered.
I think any hard fork proposal should support a reasonable number of
reasonable-size old-sighash transactions, to allow a smooth transaction of
wallet software and hardware and to support anybody who might have a
hardware wallet locked away in a safe deposit box for years.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1353 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-26 17:21 ` Gavin Andresen
@ 2017-01-26 17:41 ` Matt Corallo
0 siblings, 0 replies; 21+ messages in thread
From: Matt Corallo @ 2017-01-26 17:41 UTC (permalink / raw)
To: Gavin Andresen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
Excuse me, yes, for previously-signed transactions this is required. We might consider some limits on UTXO-chain-from-before-the-fork-length and likely something like move towards only allowing one transaction per block from the old mode over time.
I highly disagree that compatibility with existing transaction signing software should be considered (but for hardware which cannot be upgraded easily we do need to consider it). Wallets which can upgrade should, as much as possible, upgrade to a new form to maximize chain divergence and are going to end up having to upgrade to know a new header format anyway, so am extra few lines of code to change a transaction version should be trivial.
On January 26, 2017 12:21:37 PM EST, Gavin Andresen <gavinandresen@gmail•com> wrote:
>On Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <
>bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 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?
>>
>
>Compatibility with existing transaction-signing software and hardware
>should be considered.
>
>I think any hard fork proposal should support a reasonable number of
>reasonable-size old-sighash transactions, to allow a smooth transaction
>of
>wallet software and hardware and to support anybody who might have a
>hardware wallet locked away in a safe deposit box for years.
>
>--
>--
>Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2388 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-25 19:32 ` Tom Harding
@ 2017-01-27 20:47 ` Johnson Lau
2017-01-27 22:11 ` Tom Harding
0 siblings, 1 reply; 21+ messages in thread
From: Johnson Lau @ 2017-01-27 20:47 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
> On 26 Jan 2017, at 03:32, Tom Harding <tomh@thinlink•com> wrote:
>
> On 1/24/2017 8:03 PM, Johnson Lau wrote:
>> it seems they are not the same: yours is opt-out, while mine is opt-in.
>
> I missed this. So in fact you propose a self-defeating requirement on the new network, which would force unmodified yet otherwise compatible systems to change to support the new network at all. This is unlikely to be included in new network designs.
>
> I suggest that the opt-out bits proposal comes from a more realistic position that would actually make sense for everyone.
>
I think there are some misunderstanding. You’d better read my source code if my explanation is not clear.
From my understanding our proposals are the same, just with a bitwise not (~) before the network characteristic byte. So you set a bit to opt-out a network, while I set a bit to opt-in a network (and opt-out any other)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Anti-transaction replay in a hardfork
2017-01-27 20:47 ` Johnson Lau
@ 2017-01-27 22:11 ` Tom Harding
0 siblings, 0 replies; 21+ messages in thread
From: Tom Harding @ 2017-01-27 22:11 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
Johnson,
It's actually clear from your original post - you treat "all zeros" in a
special way - as the equivalent of all ones. The semantics match the
impression I got originally. Sorry we got sidetracked.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-01-27 22:11 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-24 14:33 [bitcoin-dev] Anti-transaction replay in a hardfork Johnson Lau
2017-01-24 18:52 ` Tom Harding
2017-01-25 4:03 ` Johnson Lau
2017-01-25 19:32 ` Tom Harding
2017-01-27 20:47 ` Johnson Lau
2017-01-27 22:11 ` Tom Harding
2017-01-25 1:22 ` Natanael
2017-01-25 7:05 ` Johnson Lau
2017-01-25 7:15 ` Natanael
2017-01-25 7:21 ` Johnson Lau
2017-01-25 7:29 ` Natanael
2017-01-25 7:42 ` Johnson Lau
2017-01-26 3:29 ` Matt Corallo
2017-01-26 7:03 ` Chris Priest
2017-01-26 7:14 ` Johnson Lau
2017-01-26 8:59 ` Chris Priest
2017-01-26 9:20 ` Johnson Lau
2017-01-26 10:55 ` Edmund Edgar
2017-01-26 15:58 ` Tom Harding
2017-01-26 17:21 ` Gavin Andresen
2017-01-26 17:41 ` Matt Corallo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox