Add a ECIP for adding blockchain origin to transactions.

[marcusrbrown]

DO NOT MERGE THIS PULL REQUEST UNTIL IT IS ACCEPTED AS A DRAFT

This is based off of the discussion towards the end of ethereum/EIPs#134. By adding a Origin Block Hash field to the transaction header, clients can specify the origin of a transaction which assures it can only be valid on one or more blocks.

As noted in the Ethereum discussion, clients will need to maintain a list of block numbers of current and planned fork blocks, to be able to compare the To hash. Specifying a null hash (useful for hardware or offline wallets) will assure that the transaction is valid on any compatible chain but will not offer replay protection.

[elaineo]

Thanks Marcus! Just wondering: Is this any different from just using, say, a version number in the header?
"A new field is added to the transaction header (called Origin Block Hash, formally To"

[marcusrbrown]

Yes, because as described in the ECIP, there may be situations where you want an offline transaction to always be valid on a given chain (whether it forks or not), or to lock it to a specific chain, or to a specific fork. I think you would need multiple interpretations of a version field in those case, also this unequivocally gives you the origin chain of a transaction.

I think the most contentious case would be the null hash since it has no replay protection, but that would need to be handled between the client and the user.

[elaineo]

Okay, I understand. Bitcoin uses version bits to check for compatibility between blocks. Could the header hash be checked using a masking function such as (tx.nVersion & ~expectedVersion) != 0 ?

I think that could allow for compatibility for future-dated tx's while still preserving replay protection.

[splix]

I suggest to replace "hash of the most recent fork block" with just "hash of the most recent stable block". Because clients most likely don't know about forks, it's just a block in current chain

[elaineo]

@igetgames @avtarsehra I've been outlining the implementation for this one, and it looks like for offline transactions, the user will need to specify additional options via console or command line. So it could be pretty involved to support that option.

The replay attack fix is actually a soft fork. Should we include it in a future release instead of this one, in the interest of time?

[marcusrbrown]

I was anticipating clients specifically built for offline transactions, such as CEW or hardware wallets, to use the null hash (offline) option. I don't think you would need that functionality in Geth, if that was your concern?

[elaineo]

I'm thinking of sequencing transactions with a higher nonce. Like, I could
give you a "future-dated" signed tx with a higher nonce, and it won't be
compatible in the future if the block hash changes. I believe this is
required for state channels, but am not 100% sure.

On Sun, Oct 2, 2016 at 2:25 PM, Marcus R. Brown [email protected]
wrote:

I was anticipating clients specifically built for offline transactions,
such as CEW or hardware wallets, to use the null hash (offline) option. I
don't think you would need that functionality in Geth, if that was your
concern?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACPZr2ksu7q-DqLbD9K7IrYuJYtfNK6Mks5qwCE_gaJpZM4KL5OF
.

[marcusrbrown]

Closing in favor of #10.

[elaineo]

I think it's still worthwhile to mention this, and the transaction-nonce-increase, to ethcore. They have probably spent more time looking into replay-attack-protection and may have pros/cons for the different strategies that we have not considered.

[marcusrbrown]

Reopening on @elaineo's recommendation and to polish a bit.

[avtarsehra]

@igetgames So has a decision been made on which option is the most favourable? I saw in the other PR that you wanted me to review something and agree to it. I wasn't sure which option for relay attack you were referring to. I am ok with all three options i.e. 1. Nonce offset, 2. Extra Field or 3. Mod to Signing Process. I think all have their pros and cons, obviously I have more interest in one that has minimal impact to transaction structure, but they would all equally work and solve the problem. So I would be happy to go with one that meets a consensus from everyone. I think more important to agree and move forward. So if option 2 above is chose, I would be happy.

[marcusrbrown]

@avtarsehra I wanted to confirm that you were OK for me to post your ECIP as an EIP in the relay protection thread at ethereum/EIPs#134, and make sure that you didn't have any further changes to it before it was presented.

I like option 2 the best as IMO it provides the greatest protection at a fairly cheap price. It allows us to completely separate the chains (nonce and mod would, but there are still ways to circumvent) while remaining compatible with other proposed ECIPs/EIPs and fixes. Even with the extra field, the EVM, contract deployment, consensus, etc. all remain unchanged. It also allows us to clearly separate our own forks with certainty.

I think we should present your ECIP as is with an additional option to have it represented as an extra TX field instead of an extra hashing step.

[avtarsehra]

@igetgames yes that sounds good, I'm ok with that. If you're going to submit in EIP, it would be best to include all as one post, so feel free to combine the way you think is most efficient and effective.

[realcodywburns]

Can this topic be closed?