Topic: [Idea] Replay protection by adding a new variable to transactions (Read 397 times)
I kind of like the idea of putting it right at the beginning of the transaction, before the version. You could tell what fork a raw transaction is made for at a glance, just looking at the hex. That would be harder if it were at the end or between the version and inputs.
October 27, 2017, 09:49:27 AM
As for that "flag", you can change the place of it. Put it at the end, after Sequence if you think it can cause any issues (not yet 100% familiar with SegWit 
)
between [version] and [tx_in count] )
October 27, 2017, 09:33:36 AM
So, will this work, or am I missing something here? Is there any downside to it?
This is not "work", this is "fork".
Nobody wants to call his improvements as "fork".
Quote
[Fork_flag][Version][tx_in count][tx_in]
The client should know what the first 4 bytes mean: is it old good version or new fork_flag?Do you know how segwit transactions are serialized?
In case you missed it, I am talking about these new forks that are coming out these days like bitcoin gold for example. And as they are creating a new fork, a new coin with a new client and new way of transactions, that client knows this.
As for that "flag", you can change the place of it. Put it at the end, after Sequence if you think it can cause any issues (not yet 100% familiar with SegWit
) October 27, 2017, 09:14:21 AM
So, will this work, or am I missing something here? Is there any downside to it?
This is not "work", this is "fork".
Nobody wants to call his improvements as "fork".
Quote
[Fork_flag][Version][tx_in count][tx_in]
The client should know what the first 4 bytes mean: is it old good version or new fork_flag?Do you know how segwit transactions are serialized?
October 27, 2017, 04:08:26 AM
I've been reading more about "Replay Protection" and how these forks are having trouble with it, some claiming the Sighash_forkID is hard to implement and is complicated to implement, so I was thinking there can be a much simpler way of implementing such protection.
Idea:
Add a new variable to transaction to indicate this is a transaction belonging to chain_x (bitcoin whatever chain).
For example it can be a 1 byte variable before version. Let's call it Fork_Flag
Example:
bitcoin transaction:
Since when a transaction is being signed, everything is signed, the signature of said transaction will be different. So an attacker can't just remove the first byte and "replay" that tx on bitcoin network, the signature will be invalid then.
Benefit:
- Easy to implement
- Also if a bitcoin node receives this transaction it does not have to verify the signature to know it is invalid which means not wasting CPU power. A quick look tells the node that this transaction is invalid.
So, will this work, or am I missing something here? Is there any downside to it?
Idea:
Add a new variable to transaction to indicate this is a transaction belonging to chain_x (bitcoin whatever chain).
For example it can be a 1 byte variable before version. Let's call it Fork_Flag
Example:
bitcoin transaction:
Code:
01000000017b1eabe0209b1fe794124575ef807057.... [Version][tx_in count][tx_in]....
bitcoin fork transaction: Code:
0101000000017b1eabe0209b1fe794124575ef807057.... [Fork_flag][Version][tx_in count][tx_in]....
Since when a transaction is being signed, everything is signed, the signature of said transaction will be different. So an attacker can't just remove the first byte and "replay" that tx on bitcoin network, the signature will be invalid then.
Benefit:
- Easy to implement
- Also if a bitcoin node receives this transaction it does not have to verify the signature to know it is invalid which means not wasting CPU power. A quick look tells the node that this transaction is invalid.
So, will this work, or am I missing something here? Is there any downside to it?
Jump to: