[bitcoin-dev] Anti-transaction replay in a hardfork

[Johnson Lau via bitcoin-dev]

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>

[Tom Harding via bitcoin-dev]

Post by Johnson Lau via bitcoin-dev
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.

[Johnson Lau via 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)

Post by Tom Harding via bitcoin-dev

Post by Johnson Lau via bitcoin-dev
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
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.

[Tom Harding via bitcoin-dev]

Post by Johnson Lau via bitcoin-dev
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.

[Johnson Lau via bitcoin-dev]

Post by Johnson Lau via bitcoin-dev
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)

[Tom Harding via 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.

[Natanael via bitcoin-dev]

Den 24 jan. 2017 15:33 skrev "Johnson Lau via bitcoin-dev" <
bitcoin-***@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.

[Johnson Lau via bitcoin-dev]

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.

Post by Johnson Lau via bitcoin-dev
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.

[Natanael via bitcoin-dev]

Den 25 jan. 2017 08:06 skrev "Johnson Lau" <***@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?

[Johnson Lau via bitcoin-dev]

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

Post by Johnson Lau via bitcoin-dev
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?

[Natanael via bitcoin-dev]

This post might be inappropriate. Click to display it.

[Johnson Lau via bitcoin-dev]

This post might be inappropriate. Click to display it.

[Matt Corallo via bitcoin-dev]

"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

Post by Johnson Lau via bitcoin-dev
This is a pre-BIP. Just need some formatting to make it a formal BIP
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
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.
“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
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.
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.
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)
* 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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Johnson Lau via 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.

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

Post by Matt Corallo via bitcoin-dev
"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

Post by Johnson Lau via bitcoin-dev
This is a pre-BIP. Just need some formatting to make it a formal BIP
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
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.
“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
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.
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.
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)
* 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.
A demo is available in my forcenet2
https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Johnson Lau via 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.

Post by Johnson Lau via 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...

Post by Johnson Lau via 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.

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

Post by Matt Corallo via bitcoin-dev
"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

Post by Johnson Lau via bitcoin-dev
This is a pre-BIP. Just need some formatting to make it a formal BIP
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
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.
“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
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.
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.
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)
* 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.
A demo is available in my forcenet2
https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Edmund Edgar via bitcoin-dev]

On 26 January 2017 at 18:20, Johnson Lau via bitcoin-dev

Post by Johnson Lau via bitcoin-dev
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
***@realitykeys.com
https://www.realitykeys.com

[Tom Harding via 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.

Post by Johnson Lau via bitcoin-dev
Not to mention that mining is a random process, and the hashing power is going up and down.

[Matt Corallo via bitcoin-dev]

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 Wed, Jan 25, 2017 at 10:29 PM, Matt Corallo via bitcoin-dev <

Post by Matt Corallo via bitcoin-dev
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

Post by Matt Corallo via bitcoin-dev
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