Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed

Conversation

Projects
None yet
5 participants
@igetgames
Copy link
Member

igetgames commented Oct 1, 2016

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

This comment has been minimized.

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"

@igetgames

This comment has been minimized.

Copy link
Member Author

igetgames commented Oct 2, 2016

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

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?

@igetgames

This comment has been minimized.

Copy link
Member Author

igetgames commented Oct 2, 2016

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

This comment has been minimized.

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
.

@igetgames

This comment has been minimized.

Copy link
Member Author

igetgames commented Oct 5, 2016

Closing in favor of #10.

@igetgames igetgames closed this Oct 5, 2016

@elaineo

This comment has been minimized.

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.

@igetgames

This comment has been minimized.

Copy link
Member Author

igetgames commented Oct 6, 2016

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

@igetgames igetgames reopened this Oct 6, 2016

@avtarsehra

This comment has been minimized.

Copy link

avtarsehra commented Oct 9, 2016

@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.

@igetgames

This comment has been minimized.

Copy link
Member Author

igetgames commented Oct 9, 2016

@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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor

realcodywburns commented Feb 12, 2017

Can this topic be closed?

@elaineo elaineo added the withdrawn label Apr 30, 2017

@elaineo elaineo closed this Apr 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.