Skip to content
This repository has been archived by the owner on Oct 4, 2019. It is now read-only.

Add a ECIP for adding blockchain origin to transactions. #9

Conversation

marcusrbrown
Copy link
Contributor

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
Copy link
Member

elaineo commented Oct 2, 2016

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
Copy link
Contributor Author

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
Copy link
Member

elaineo commented Oct 2, 2016

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
Copy link
Contributor

splix commented Oct 2, 2016

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
Copy link
Member

elaineo commented Oct 2, 2016

@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
Copy link
Contributor Author

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
Copy link
Member

elaineo commented Oct 2, 2016

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 notifications@github.com
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
Copy link
Contributor Author

Closing in favor of #10.

@elaineo
Copy link
Member

elaineo commented Oct 5, 2016

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
Copy link
Contributor Author

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

@marcusrbrown marcusrbrown reopened this Oct 6, 2016
@avtarsehra
Copy link

@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
Copy link
Contributor Author

@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
Copy link

avtarsehra commented Oct 9, 2016

@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 realcodywburns added this to the Active milestone Oct 25, 2016
@realcodywburns
Copy link
Contributor

Can this topic be closed?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants