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

Abstraction of transaction origin and signature.md #208

Merged
merged 10 commits into from Mar 27, 2018

Conversation

@vbuterin
Collaborator

vbuterin commented Feb 10, 2017

Implements a set of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

Create abstraction.md
Implements a set of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.
@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Feb 25, 2017

Member

Can we make the title more descriptive? How about something like "Abstraction of transaction origin and signature"

Member

cdetrio commented Feb 25, 2017

Can we make the title more descriptive? How about something like "Abstraction of transaction origin and signature"

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 1, 2017

Member

I see a change about nonce increment in https://github.com/ethcore/parity/pull/4697 (line: https://github.com/ethcore/parity/blob/027b0446efa48622ce166a561dd274332dac96a0/ethcore/src/executive.rs#L178 ) but not in this PR. I don't have a strong opinion, but need to know which to follow. Now I think, nonce increment or nonce checking should be disabled on NULL_SENDER. Otherwise, transaction signers need to compete for the current nonce for no particular benefits.

Member

pirapira commented Mar 1, 2017

I see a change about nonce increment in https://github.com/ethcore/parity/pull/4697 (line: https://github.com/ethcore/parity/blob/027b0446efa48622ce166a561dd274332dac96a0/ethcore/src/executive.rs#L178 ) but not in this PR. I don't have a strong opinion, but need to know which to follow. Now I think, nonce increment or nonce checking should be disabled on NULL_SENDER. Otherwise, transaction signers need to compete for the current nonce for no particular benefits.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 1, 2017

Member

@yann300 is also working on this.

Member

pirapira commented Mar 1, 2017

@yann300 is also working on this.

Show outdated Hide outdated EIPS/abstraction.md
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`
2. Set the address of any contract created through a creation transaction to equal `sha3(NULL_SENDER + sha3(init code)) % 2**160`, where `+` represents concatenation, replacing the earlier address formula of `sha3(rlp.encode([sender, nonce]))`
3. Create a new opcode at `0xfb`, `CREATE_P2SH`, which sets the creation address to `sha3(sender + sha3(init code)) % 2**160`. If a contract at that address already exists, fails and returns 0 as if the init code had run out of gas.

This comment has been minimized.

@pirapira

pirapira Mar 2, 2017

Member

Does the last sentence ("If a contract at that address already exists,...") apply to CREATE opcode and creation by external accounts?

@pirapira

pirapira Mar 2, 2017

Member

Does the last sentence ("If a contract at that address already exists,...") apply to CREATE opcode and creation by external accounts?

@rphmeier

This comment has been minimized.

Show comment
Hide comment
@rphmeier

rphmeier Mar 7, 2017

Collaborator

@pirapira

I think, nonce increment or nonce checking should be disabled on NULL_SENDER.

Yes, absolutely. We'll also have to make it work with the dust protection EIP.
Probably nonce checking should also be disabled, or we should make a distinction between transactions abstracted from NULL_SENDER and transactions actually signed by NULL_SENDER

Collaborator

rphmeier commented Mar 7, 2017

@pirapira

I think, nonce increment or nonce checking should be disabled on NULL_SENDER.

Yes, absolutely. We'll also have to make it work with the dust protection EIP.
Probably nonce checking should also be disabled, or we should make a distinction between transactions abstracted from NULL_SENDER and transactions actually signed by NULL_SENDER

@arkpar arkpar referenced this pull request Mar 9, 2017

Closed

Byzantium release #4833

12 of 12 tasks complete
Show outdated Hide outdated EIPS/abstraction.md
### Specification
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`

This comment has been minimized.

@gumb0

gumb0 Mar 13, 2017

Member

Was v = CHAIN_ID really the intention here?
Currently according to #155 v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36
(implemented only as v = CHAIN_ID * 2 + 35 in cpp-ethereum)

So do we really need additional v rule for zero signature instead of following EIP155 here, too?

@gumb0

gumb0 Mar 13, 2017

Member

Was v = CHAIN_ID really the intention here?
Currently according to #155 v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36
(implemented only as v = CHAIN_ID * 2 + 35 in cpp-ethereum)

So do we really need additional v rule for zero signature instead of following EIP155 here, too?

This comment has been minimized.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

There are two ways in which v is set in EIP 155. The first is the v value which appears in the actual transaction. This is set according to that formula. The second is the value which is put into the v slot when computing the hash. This is set to equal the CHAIN_ID, just as here.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

There are two ways in which v is set in EIP 155. The first is the v value which appears in the actual transaction. This is set according to that formula. The second is the value which is put into the v slot when computing the hash. This is set to equal the CHAIN_ID, just as here.

This comment has been minimized.

@gumb0

gumb0 Apr 28, 2017

Member

So v here in this EIP refers not to the actual value in Tx RLP, but to the one extracted from it using EIP155 formula, right?

@gumb0

gumb0 Apr 28, 2017

Member

So v here in this EIP refers not to the actual value in Tx RLP, but to the one extracted from it using EIP155 formula, right?

This comment has been minimized.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

Aah! I see what you mean, sorry I take back my previous comment. I would still prefer v in the transaction being equal to the chain ID, as that's the easiest thing to do. There is no need to set the v value to 35 + chain_id * 2 here.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

Aah! I see what you mean, sorry I take back my previous comment. I would still prefer v in the transaction being equal to the chain ID, as that's the easiest thing to do. There is no need to set the v value to 35 + chain_id * 2 here.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Mar 17, 2017

Contributor

Some questions about zero-sig transaction:

what should be the standart transaction fields (gas, gasPrice, nonce) encoded in RLP?
does this zero-sig transaction follow the rules as all other transactions (except signature)?
this transaction still charge transaction call gasPrice?
what if 0xfffffff has not enough founds?
what if 0xfffffff has enough founds?
could this transaction be sent to other then the fowarding contract?
could this transaction create new contract?
if this transaction should always has gasPrice set to 0, how would miners know to accept it?

Contributor

winsvega commented Mar 17, 2017

Some questions about zero-sig transaction:

what should be the standart transaction fields (gas, gasPrice, nonce) encoded in RLP?
does this zero-sig transaction follow the rules as all other transactions (except signature)?
this transaction still charge transaction call gasPrice?
what if 0xfffffff has not enough founds?
what if 0xfffffff has enough founds?
could this transaction be sent to other then the fowarding contract?
could this transaction create new contract?
if this transaction should always has gasPrice set to 0, how would miners know to accept it?

Show outdated Hide outdated EIPS/abstraction.md
### Specification
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`

This comment has been minimized.

@chriseth

chriseth Mar 21, 2017

Contributor

This is not formatted correctly.

@chriseth

chriseth Mar 21, 2017

Contributor

This is not formatted correctly.

Show outdated Hide outdated EIPS/abstraction.md
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`
2. Set the address of any contract created through a creation transaction to equal `sha3(NULL_SENDER + sha3(init code)) % 2**160`, where `+` represents concatenation, replacing the earlier address formula of `sha3(rlp.encode([sender, nonce]))`

This comment has been minimized.

@chriseth

chriseth Mar 21, 2017

Contributor

I assume this only applies to transactions with r = s = 0. Is that correct? So we have:
If such a transaction has a to value of zero (i.e is a creation transaction), set the address of the created contract to sha3(NULL_SENDER + sha3(txdata)) % 2**160, .... If an account at that address already exists (TODO correctly specify existence), the transaction is considered invalid.

@chriseth

chriseth Mar 21, 2017

Contributor

I assume this only applies to transactions with r = s = 0. Is that correct? So we have:
If such a transaction has a to value of zero (i.e is a creation transaction), set the address of the created contract to sha3(NULL_SENDER + sha3(txdata)) % 2**160, .... If an account at that address already exists (TODO correctly specify existence), the transaction is considered invalid.

This comment has been minimized.

@pirapira

pirapira Mar 21, 2017

Member
  • I understood that this applies to all contract creations.
  • I think we should keep allowing creating contracts on existing accounts (e.g. with positive balance).
@pirapira

pirapira Mar 21, 2017

Member
  • I understood that this applies to all contract creations.
  • I think we should keep allowing creating contracts on existing accounts (e.g. with positive balance).
@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Mar 21, 2017

Contributor

Do we want to lower the gas costs for such transactions (i.e. the transaction itself) since ecrecover does not have to be called to check the signature.

Contributor

chriseth commented Mar 21, 2017

Do we want to lower the gas costs for such transactions (i.e. the transaction itself) since ecrecover does not have to be called to check the signature.

@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin Mar 21, 2017

Collaborator

So there are two paths to resolving this:

  1. We implement the EIP as is, so we keep the gasPrice mechanism, keep the nonce checking, just make a (0, 0, 0) sig represent a NULL_SENDER with no other changes to the protocol. For practicality we can add a special-case rule that the nonce of NULL_SENDER is always 0 and never increments.
  2. We add extra rules:
  • The nonce of an EIP 86 transaction MUST be 0
  • The gasprice of an EIP 86 transaction MUST be 0
  • The value of an EIP 86 transaction MUST be 0

EIP 86 transactions can create new contracts if the "to" field is empty.

This looks ugly in either case, as we have useless vestigial fields that hang around like an appendix, but IMO we should make a future HF which modifies TX formats more substantially and makes them more logical, for example including a proper field for the network ID and the transaction version number, and past the HF making old-style transactions no longer valid. IMO we have to do this eventually, as if we do not, then every time we make new tx formats or change tx formats we incur more and more technical debt. If we really feel daring, I can make an EIP for doing this now, so we can just not do EIP 86 at all.

Collaborator

vbuterin commented Mar 21, 2017

So there are two paths to resolving this:

  1. We implement the EIP as is, so we keep the gasPrice mechanism, keep the nonce checking, just make a (0, 0, 0) sig represent a NULL_SENDER with no other changes to the protocol. For practicality we can add a special-case rule that the nonce of NULL_SENDER is always 0 and never increments.
  2. We add extra rules:
  • The nonce of an EIP 86 transaction MUST be 0
  • The gasprice of an EIP 86 transaction MUST be 0
  • The value of an EIP 86 transaction MUST be 0

EIP 86 transactions can create new contracts if the "to" field is empty.

This looks ugly in either case, as we have useless vestigial fields that hang around like an appendix, but IMO we should make a future HF which modifies TX formats more substantially and makes them more logical, for example including a proper field for the network ID and the transaction version number, and past the HF making old-style transactions no longer valid. IMO we have to do this eventually, as if we do not, then every time we make new tx formats or change tx formats we incur more and more technical debt. If we really feel daring, I can make an EIP for doing this now, so we can just not do EIP 86 at all.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 21, 2017

Member

@winsvega miners can, for example, whitelist contracts that pay the current miner (by calling COINBASE). The miners can, for example, include EIP86 transactions only if they call the whitelisted contracts. These are example miner strategies and we do not have to specify this in EIPs.

Member

pirapira commented Mar 21, 2017

@winsvega miners can, for example, whitelist contracts that pay the current miner (by calling COINBASE). The miners can, for example, include EIP86 transactions only if they call the whitelisted contracts. These are example miner strategies and we do not have to specify this in EIPs.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Mar 21, 2017

Contributor

if it has gasprice of 0 and can create contracts would not it mean that such transaction could spam contracts?

lets define YP rules for zero sig transactions so we could define the concrete tests for that

Contributor

winsvega commented Mar 21, 2017

if it has gasprice of 0 and can create contracts would not it mean that such transaction could spam contracts?

lets define YP rules for zero sig transactions so we could define the concrete tests for that

@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Mar 21, 2017

Contributor

It is not the gas price that limits the spam, it is the block gas limit.

Contributor

chriseth commented Mar 21, 2017

It is not the gas price that limits the spam, it is the block gas limit.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Mar 21, 2017

Contributor

So anyone will be able to create contracts for free?

Contributor

winsvega commented Mar 21, 2017

So anyone will be able to create contracts for free?

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 21, 2017

Member

@winsvega That's already the case before this EIP if you mine a block that includes your transactions with gas price being zero.

Member

pirapira commented Mar 21, 2017

@winsvega That's already the case before this EIP if you mine a block that includes your transactions with gas price being zero.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Mar 21, 2017

Contributor

right. but miniers would most likely refuse such transactions.
not the case with zero sig transactions

Contributor

winsvega commented Mar 21, 2017

right. but miniers would most likely refuse such transactions.
not the case with zero sig transactions

@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Mar 21, 2017

Contributor

@winsvega it is the same thing. If the zero-sig transaction does not send money to the miner, miners will likely refuse to include it.

Contributor

chriseth commented Mar 21, 2017

@winsvega it is the same thing. If the zero-sig transaction does not send money to the miner, miners will likely refuse to include it.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Mar 21, 2017

Contributor

I am confused. so the gasPrice needs to be > 0 ?

Contributor

winsvega commented Mar 21, 2017

I am confused. so the gasPrice needs to be > 0 ?

@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Mar 21, 2017

Contributor

zero-sig transactions send money to the miner as part of their execution and not as part of the surrounding framework, so gas price should be zero.

Contributor

chriseth commented Mar 21, 2017

zero-sig transactions send money to the miner as part of their execution and not as part of the surrounding framework, so gas price should be zero.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 21, 2017

Member

@winsvega When a miner is constructing a block, the miner can freely exclude transactions. One strategy is doing nothing special about EIP86 transactions (then gasPrice = 0 would be rejected). Another strategy is to exclude all EIP86 transactions. Another strategy is to exclude all EIP86 transactions unless they send Ether to the miner (e.g. a contract CALLs the miner with some value). Then, EIP86 transactions with gasPrice = 0 might be included. An approximation of the previous strategy is to whitelist contracts that pay miners (by CALL ing COINBASE with some value), and exclude all EIP86 transactions except on these whitelisted contracts. Miner strategies are not documented in the EIP.

For somebody sending an EIP86 transaction, it does not make much sense to set gasPrice > 0 because any balance on the null-sender would be quickly be sent away somewhere. So the transaction sender needs a way to pay the miners during EIP86 transactions, and persuade miners to include the EIP86 transactions. The transaction signing strategies are not documented in the EIP.

When this kind of coordination takes place between the transaction senders and the miners, we will see EIP86 transactions in blocks. This coordination between the senders and the miners is not part of the protocol. Even local agreements can exist.

Member

pirapira commented Mar 21, 2017

@winsvega When a miner is constructing a block, the miner can freely exclude transactions. One strategy is doing nothing special about EIP86 transactions (then gasPrice = 0 would be rejected). Another strategy is to exclude all EIP86 transactions. Another strategy is to exclude all EIP86 transactions unless they send Ether to the miner (e.g. a contract CALLs the miner with some value). Then, EIP86 transactions with gasPrice = 0 might be included. An approximation of the previous strategy is to whitelist contracts that pay miners (by CALL ing COINBASE with some value), and exclude all EIP86 transactions except on these whitelisted contracts. Miner strategies are not documented in the EIP.

For somebody sending an EIP86 transaction, it does not make much sense to set gasPrice > 0 because any balance on the null-sender would be quickly be sent away somewhere. So the transaction sender needs a way to pay the miners during EIP86 transactions, and persuade miners to include the EIP86 transactions. The transaction signing strategies are not documented in the EIP.

When this kind of coordination takes place between the transaction senders and the miners, we will see EIP86 transactions in blocks. This coordination between the senders and the miners is not part of the protocol. Even local agreements can exist.

@winsvega

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Mar 21, 2017

Contributor

so the actual payment for the transaction will be done by a contract that decode data of the zero sig transaction, is that right?

we still have the nonce problem that Andrei mentioned if we do not implement nonce = 0 rule.

the practical problem with nonce checking as I see it - when everyone can send zero sig transactions, and we can have several of them in each block, most of them will be invalid becaus of incorrect nonce
you can't guess the correct nonce when constructing the tx, since anyone else can increment it

or like we already did we could just drop nonce checking for zero sig transactions.
then I guess gasPrice and gasLimit could stay and be verified as for regular transactions.

what I mean by YP rules is that we have to define for zero sig transaction
that everyone would agree

  1. the nonce checking
  2. the gasLimit/gasPrice charge/checking
  3. the value transfer (allow/disallow)
  4. contract creation
Contributor

winsvega commented Mar 21, 2017

so the actual payment for the transaction will be done by a contract that decode data of the zero sig transaction, is that right?

we still have the nonce problem that Andrei mentioned if we do not implement nonce = 0 rule.

the practical problem with nonce checking as I see it - when everyone can send zero sig transactions, and we can have several of them in each block, most of them will be invalid becaus of incorrect nonce
you can't guess the correct nonce when constructing the tx, since anyone else can increment it

or like we already did we could just drop nonce checking for zero sig transactions.
then I guess gasPrice and gasLimit could stay and be verified as for regular transactions.

what I mean by YP rules is that we have to define for zero sig transaction
that everyone would agree

  1. the nonce checking
  2. the gasLimit/gasPrice charge/checking
  3. the value transfer (allow/disallow)
  4. contract creation
@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 21, 2017

Member

1 and 2: I think Vitalik's two options both work (but the first option with never-increasing nonce)

3 Disallowing the value transfer would enable an undesired course of events. The null sender receives some large amount by accident, but nobody can send it anywhere, so everyone starts using the null sender's wealth to pay for gas. That's undesired. I prefer allowing value transfer from the null sender because the null sender's wealth will be there only for a short period.

I think the point of this EIP is to specify less and less in the protocol and let the transaction senders and the miners decide.

Member

pirapira commented Mar 21, 2017

1 and 2: I think Vitalik's two options both work (but the first option with never-increasing nonce)

3 Disallowing the value transfer would enable an undesired course of events. The null sender receives some large amount by accident, but nobody can send it anywhere, so everyone starts using the null sender's wealth to pay for gas. That's undesired. I prefer allowing value transfer from the null sender because the null sender's wealth will be there only for a short period.

I think the point of this EIP is to specify less and less in the protocol and let the transaction senders and the miners decide.

@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin Mar 21, 2017

Collaborator

Here's my EIP for fully "cleaning house" and making new tx types. It's much more work, but in the long run IMO something like this will be necessary.

#232

Collaborator

vbuterin commented Mar 21, 2017

Here's my EIP for fully "cleaning house" and making new tx types. It's much more work, but in the long run IMO something like this will be necessary.

#232

@tomusdrw

This comment has been minimized.

Show comment
Hide comment
@tomusdrw

tomusdrw Mar 23, 2017

What if the transaction goes OOG or uses REVERT at the very end?
Such transaction would be included in the block anyway, but miner will not get the fee, cause all state changes are reverted.

EDIT:
Please disregard the question, I've mistakenly thought that a subcall can cause the entire transaction to be reverted, but that's obviously not the case. So if the top-level contract code is sound, miners/nodes can indeed check if the fee is paid in the first few steps of the contract and include/relay the transaction.

tomusdrw commented Mar 23, 2017

What if the transaction goes OOG or uses REVERT at the very end?
Such transaction would be included in the block anyway, but miner will not get the fee, cause all state changes are reverted.

EDIT:
Please disregard the question, I've mistakenly thought that a subcall can cause the entire transaction to be reverted, but that's obviously not the case. So if the top-level contract code is sound, miners/nodes can indeed check if the fee is paid in the first few steps of the contract and include/relay the transaction.

@vbuterin vbuterin changed the title from Create abstraction.md to Abstraction of transaction origin and signature.md Mar 24, 2017

Show outdated Hide outdated EIPS/abstraction.md
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`
2. Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account 0.
3. Set the address of any contract created through a creation transaction to equal `sha3(NULL_SENDER + sha3(init code)) % 2**160`, where `+` represents concatenation, replacing the earlier address formula of `sha3(rlp.encode([sender, nonce]))`

This comment has been minimized.

@pirapira

pirapira Apr 12, 2017

Member

Why does this change apply only to creation transactions but not to the CREATE instruction?

@pirapira

pirapira Apr 12, 2017

Member

Why does this change apply only to creation transactions but not to the CREATE instruction?

This comment has been minimized.

@axic

axic Apr 20, 2017

Member

I guess the reasoning is that changing the CREATE opcode can break contracts, while changing the external interface will not.

@axic

axic Apr 20, 2017

Member

I guess the reasoning is that changing the CREATE opcode can break contracts, while changing the external interface will not.

This comment has been minimized.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

Correct. It's much easier for external actors to adjust to this (eg. by creating any contracts that they planned to create before the hard fork kicks in) than for contracts.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

Correct. It's much easier for external actors to adjust to this (eg. by creating any contracts that they planned to create before the hard fork kicks in) than for contracts.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Apr 14, 2017

Collaborator

Please rename and renumber to eip-208.md, and we can merge as draft.

Collaborator

Arachnid commented Apr 14, 2017

Please rename and renumber to eip-208.md, and we can merge as draft.

Show outdated Hide outdated EIPS/abstraction.md
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`
2. Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account 0.
3. Set the address of any contract created through a creation transaction to equal `sha3(NULL_SENDER + sha3(init code)) % 2**160`, where `+` represents concatenation, replacing the earlier address formula of `sha3(rlp.encode([sender, nonce]))`

This comment has been minimized.

@yann300

yann300 Apr 18, 2017

  1. apply to CREATE?
@yann300

yann300 Apr 18, 2017

  1. apply to CREATE?

This comment has been minimized.

@pirapira

pirapira Apr 21, 2017

Member
  1. does not apply to CREATE I heard in ethereum/pm#12
@pirapira

pirapira Apr 21, 2017

Member
  1. does not apply to CREATE I heard in ethereum/pm#12
Show outdated Hide outdated EIPS/abstraction.md
* CHAIN_ID: same as used for EIP 155 (ie. 1 for mainnet, 3 for testnet)
* NULL_SENDER: 2**160 - 1
### Specification

This comment has been minimized.

@yann300

yann300 Apr 18, 2017

could we clarify that MaxAddress can be cleared? (sender be touched?)

@yann300

yann300 Apr 18, 2017

could we clarify that MaxAddress can be cleared? (sender be touched?)

This comment has been minimized.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

What's MaxAddress?

@vbuterin

vbuterin Apr 28, 2017

Collaborator

What's MaxAddress?

This comment has been minimized.

@winsvega

winsvega Apr 28, 2017

Contributor

NULL_SENDER

@winsvega

winsvega Apr 28, 2017

Contributor

NULL_SENDER

Show outdated Hide outdated EIPS/abstraction.md
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`
2. Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account 0.
3. Set the address of any contract created through a creation transaction to equal `sha3(NULL_SENDER + sha3(init code)) % 2**160`, where `+` represents concatenation, replacing the earlier address formula of `sha3(rlp.encode([sender, nonce]))`
4. Create a new opcode at `0xfb`, `CREATE_P2SH`, which sets the creation address to `sha3(sender + sha3(init code)) % 2**160`. If a contract at that address already exists, fails and returns 0 as if the init code had run out of gas.

This comment has been minimized.

@axic

axic Apr 20, 2017

Member

I think we shouldn't name this P2SH as it is not about "paying to script hash". Even CREATE2 may be better.

This should also define the actual parameters to the opcode. Is it only code and gas?

@axic

axic Apr 20, 2017

Member

I think we shouldn't name this P2SH as it is not about "paying to script hash". Even CREATE2 may be better.

This should also define the actual parameters to the opcode. Is it only code and gas?

This comment has been minimized.

@yann300

yann300 Apr 27, 2017

@chriseth @vbuterin ?
do we have those params for the new create opcode? => value, data offset, length

@yann300

yann300 Apr 27, 2017

@chriseth @vbuterin ?
do we have those params for the new create opcode? => value, data offset, length

This comment has been minimized.

@winsvega

winsvega Apr 27, 2017

Contributor

also what is the ORIGIN for the newly created contract by CREATE2?

@winsvega

winsvega Apr 27, 2017

Contributor

also what is the ORIGIN for the newly created contract by CREATE2?

This comment has been minimized.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

Everything about CREATE2 should be exactly the same as create, except that the way the address is generated is different. So, params are value, data offset, length, and ORIGIN is the tx origin.

@vbuterin

vbuterin Apr 28, 2017

Collaborator

Everything about CREATE2 should be exactly the same as create, except that the way the address is generated is different. So, params are value, data offset, length, and ORIGIN is the tx origin.

Show outdated Hide outdated EIPS/abstraction.md
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`
2. Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account NULL_SENDER.
3. Set the address of any contract created through a creation transaction (whether of the traditional or the EIP86 variety) to equal `sha3(NULL_SENDER + sha3(init code)) % 2**160`, where `+` represents concatenation, replacing the earlier address formula of `sha3(rlp.encode([sender, nonce]))`

This comment has been minimized.

@pirapira

pirapira Jul 4, 2017

Member

Some people say this point was changed in ethereum/pm#17 so that the earlier address formula survives when the sender is not NULL_SENDER.

@pirapira

pirapira Jul 4, 2017

Member

Some people say this point was changed in ethereum/pm#17 so that the earlier address formula survives when the sender is not NULL_SENDER.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Jul 6, 2017

Member

Just a confirmation: NULL_SENDER can only create one contract at sha(rlp.encode([NULL_SENDER, 0])) and nowhere else.

Member

pirapira commented on bd136e6 Jul 6, 2017

Just a confirmation: NULL_SENDER can only create one contract at sha(rlp.encode([NULL_SENDER, 0])) and nowhere else.

@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Jul 8, 2017

Member

At the All Core Devs meeting #19 it was suggested that we consider deferring EIP 86 (also known as EIP 208) from inclusion in Metropolis. If deferred, then EIP 86 (or a superseding transaction/account abstraction EIP) would be rescheduled for a "Metropolis Part B" fork.

EIP 86 includes two separate features: "null sender" transactions and "create2" contract addresses. Concerns around these features include:

  1. NULL_SENDER transactions break the existing invariant that tx hashes are unique (no tx can be included more than once in the chain). Although this is not expected to affect the EVM or client consensus, the behavior of RPC methods such as eth_getTransactionByHash and eth_getTransactionReceipt would have to be redefined, and new behaviors that violate old assumptions about transaction hashes may become problematic for users. (Note that a similar tx malleability problem existed prior to Homestead, when two functionally identical transactions could have different hashes.) [1]

  2. CREATE2 breaks the existing invariant that deployed contract code may only be deleted, not replaced with new code. Currently, a deployed contract's code can be deleted with SELFDESTRUCT, but the code thereafter is guaranteed to remain empty. CREATE2 would enable deploying new code at a previously deleted contract's address. [2]

A concern about "address collision attacks" had to do with an earlier version of the spec, where traditional transactions would create contracts using new CREATE2 addresses (sha3(NULL_SENDER + sha3(init code)) % 2**160). This concern was alleviated by modifying the spec so that traditional transactions will continue to create contracts using traditional addresses sha3(rlp.encode([sender, nonce])). [3]

In deciding whether to defer EIP 86, other trade-offs to evaluate include:

  • Possibly modifying the behavior of the ORIGIN opcode (tx.origin in Solidity) for NULL_SENDER transactions. [4]

  • The NULL_SENDER transaction format is merely a space-saving optimization, and not strictly necessary to enable some immediate use cases like "contracts can pay for gas". [5]

  • NULL_SENDER transaction usage will not be widespread until miner strategies for processing transactions to "forwarding contracts" are developed and adopted.

  • The NULL_SENDER transaction format is a stopgap that introduces technical debt before a more substantial format change in the future. [6][7]

References

  1. #208 (comment) - on tx hash uniqueness

  2. #208 (comment) - mutable contracts

  3. #208 (comment) - address collision attacks

  4. #208 (comment) - NULL_SENDER and tx.origin

  5. #86 (comment) - "The problem is that if you have a forwarding contract without EIP 86, then you are wasting 96 bytes and a signature recovery operation."

  6. #208 (comment)

[EIP 86 transactions] look ugly in either case, as we have useless vestigial fields that hang around like an appendix, but IMO we should make a future HF which modifies TX formats more substantially and makes them more logical, for example including a proper field for the network ID and the transaction version number, and past the HF making old-style transactions no longer valid. IMO we have to do this eventually, as if we do not, then every time we make new tx formats or change tx formats we incur more and more technical debt. If we really feel daring, I can make an EIP for doing this now, so we can just not do EIP 86 at all.

  1. #232 - New transaction formats
Member

cdetrio commented Jul 8, 2017

At the All Core Devs meeting #19 it was suggested that we consider deferring EIP 86 (also known as EIP 208) from inclusion in Metropolis. If deferred, then EIP 86 (or a superseding transaction/account abstraction EIP) would be rescheduled for a "Metropolis Part B" fork.

EIP 86 includes two separate features: "null sender" transactions and "create2" contract addresses. Concerns around these features include:

  1. NULL_SENDER transactions break the existing invariant that tx hashes are unique (no tx can be included more than once in the chain). Although this is not expected to affect the EVM or client consensus, the behavior of RPC methods such as eth_getTransactionByHash and eth_getTransactionReceipt would have to be redefined, and new behaviors that violate old assumptions about transaction hashes may become problematic for users. (Note that a similar tx malleability problem existed prior to Homestead, when two functionally identical transactions could have different hashes.) [1]

  2. CREATE2 breaks the existing invariant that deployed contract code may only be deleted, not replaced with new code. Currently, a deployed contract's code can be deleted with SELFDESTRUCT, but the code thereafter is guaranteed to remain empty. CREATE2 would enable deploying new code at a previously deleted contract's address. [2]

A concern about "address collision attacks" had to do with an earlier version of the spec, where traditional transactions would create contracts using new CREATE2 addresses (sha3(NULL_SENDER + sha3(init code)) % 2**160). This concern was alleviated by modifying the spec so that traditional transactions will continue to create contracts using traditional addresses sha3(rlp.encode([sender, nonce])). [3]

In deciding whether to defer EIP 86, other trade-offs to evaluate include:

  • Possibly modifying the behavior of the ORIGIN opcode (tx.origin in Solidity) for NULL_SENDER transactions. [4]

  • The NULL_SENDER transaction format is merely a space-saving optimization, and not strictly necessary to enable some immediate use cases like "contracts can pay for gas". [5]

  • NULL_SENDER transaction usage will not be widespread until miner strategies for processing transactions to "forwarding contracts" are developed and adopted.

  • The NULL_SENDER transaction format is a stopgap that introduces technical debt before a more substantial format change in the future. [6][7]

References

  1. #208 (comment) - on tx hash uniqueness

  2. #208 (comment) - mutable contracts

  3. #208 (comment) - address collision attacks

  4. #208 (comment) - NULL_SENDER and tx.origin

  5. #86 (comment) - "The problem is that if you have a forwarding contract without EIP 86, then you are wasting 96 bytes and a signature recovery operation."

  6. #208 (comment)

[EIP 86 transactions] look ugly in either case, as we have useless vestigial fields that hang around like an appendix, but IMO we should make a future HF which modifies TX formats more substantially and makes them more logical, for example including a proper field for the network ID and the transaction version number, and past the HF making old-style transactions no longer valid. IMO we have to do this eventually, as if we do not, then every time we make new tx formats or change tx formats we incur more and more technical debt. If we really feel daring, I can make an EIP for doing this now, so we can just not do EIP 86 at all.

  1. #232 - New transaction formats
Show outdated Hide outdated EIPS/abstraction.md
### Parameters
* METROPOLIS_FORK_BLKNUM: TBD

This comment has been minimized.

@pirapira

pirapira Aug 2, 2017

Member

Now this should say CONSTANTINOPLE_FORK_BLKNUM.

@pirapira

pirapira Aug 2, 2017

Member

Now this should say CONSTANTINOPLE_FORK_BLKNUM.

Show outdated Hide outdated EIPS/abstraction.md
If `block.number >= METROPOLIS_FORK_BLKNUM`, then:
1. If the signature of a transaction is `(CHAIN_ID, 0, 0)` (ie. `r = s = 0`, `v = CHAIN_ID`), then treat it as valid and set the sender address to `NULL_SENDER`
2. Transactions of this form MUST have gasprice = 0, nonce = 0, value = 0, and do NOT increment the nonce of account NULL_SENDER.
3. Create a new opcode at `0xfb`, `CREATE2`, with 4 stack arguments (value, salt, mem_start, mem_size) which sets the creation address to `sha3(sender + salt + sha3(init code)) % 2**160`, where `salt` is always represented as a 32-byte value.

This comment has been minimized.

@jimpo

jimpo Sep 20, 2017

Is + uint256 addition or concatenation?

@jimpo

jimpo Sep 20, 2017

Is + uint256 addition or concatenation?

Show outdated Hide outdated EIPS/abstraction.md
tx_nonce = ~calldataload(96)
tx_to = ~calldataload(128)
tx_value = ~calldataload(160)
tx_gasprice = ~calldataload(192)

This comment has been minimized.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

There's no gas limit included like in the yellow paper. What's the rationale for that? Rather the gas limit is fixed below as 50000, which doesn't seem right given we vary the gas limit.

Another thing that confuses me is that the yellow paper instructions don't look like they take variable arguments, e.g. all instructions take an operand starting from the first item then if there are more items consecutively going up the items in the stack, memory, or other data. But this code uses e.g. sload(-1), and mstore(signing data). So it might be helpful to revise the yellow paper to point out that the opcodes can take variable arguments (provided they are within the data that is called), not just, for example, having to work first with the first item in storage or memory.

screenshot from 2017-10-06 15-29-39

From the above screenshot it looks like calldataload just loads the first input data item to the first word in memory. But given that they are known as opcodes, thus implying operators, it makes sense that they take at least one or more operands.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

There's no gas limit included like in the yellow paper. What's the rationale for that? Rather the gas limit is fixed below as 50000, which doesn't seem right given we vary the gas limit.

Another thing that confuses me is that the yellow paper instructions don't look like they take variable arguments, e.g. all instructions take an operand starting from the first item then if there are more items consecutively going up the items in the stack, memory, or other data. But this code uses e.g. sload(-1), and mstore(signing data). So it might be helpful to revise the yellow paper to point out that the opcodes can take variable arguments (provided they are within the data that is called), not just, for example, having to work first with the first item in storage or memory.

screenshot from 2017-10-06 15-29-39

From the above screenshot it looks like calldataload just loads the first input data item to the first word in memory. But given that they are known as opcodes, thus implying operators, it makes sense that they take at least one or more operands.

This comment has been minimized.

@holiman

holiman Oct 6, 2017

Contributor

In the YP, on the image above, the CALLDATALOAD 1 1 : that means it pops one off the stack and pushes one off the stack. So it takes one operand/parameter and returns one.

The CALLDATALOAD just places the data on the stack, does nothing with memory. The CALLDATACOPY is the one to use for getting it into memory.

@holiman

holiman Oct 6, 2017

Contributor

In the YP, on the image above, the CALLDATALOAD 1 1 : that means it pops one off the stack and pushes one off the stack. So it takes one operand/parameter and returns one.

The CALLDATALOAD just places the data on the stack, does nothing with memory. The CALLDATACOPY is the one to use for getting it into memory.

This comment has been minimized.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

OK, my mistake, obviously I didn't read it carefully, didn't check and think carefully about what I was writing was valid, and maybe was getting it mixed up with other opcodes that do involve memory. Thanks for clarifying.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

OK, my mistake, obviously I didn't read it carefully, didn't check and think carefully about what I was writing was valid, and maybe was getting it mixed up with other opcodes that do involve memory. Thanks for clarifying.

Show outdated Hide outdated EIPS/abstraction.md
```python
# Get signature from tx data
sig_v = ~calldataload(0)

This comment has been minimized.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

When I first read this with the ~ I found it confusing as it is used to invert all the bits in Python, which is equivalent to ~x = -x - 1.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

When I first read this with the ~ I found it confusing as it is used to invert all the bits in Python, which is equivalent to ~x = -x - 1.

Show outdated Hide outdated EIPS/abstraction.md
~calldataload(signing_data + 32, 96, ~calldatasize() - 96)
signing_hash = sha3(signing_data:str)
# Perform usual checks
prev_nonce = ~sload(-1)

This comment has been minimized.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

~sload(-1) reads the last word in storage, which is presumably where the nonce is stored. I'm not sure where this is defined in the current version of the yellow paper. The prev_nonce would be the nonce of the sender account. In the yellow paper the account nonce is the first item in the state.

Word # in stack/ stack item no. initial stack bytes
1 v 0
2 r 32
3 s 64
4 nonce 96
5 to 128
6 value 160
7 gasprice 192
8 data 224

Addresses are 160 bits, but above it sets aside 32 bytes, but I guess it does that for efficiency with extracting it, rather than performing bitwise operation on a word, where other data is stored in the word.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

~sload(-1) reads the last word in storage, which is presumably where the nonce is stored. I'm not sure where this is defined in the current version of the yellow paper. The prev_nonce would be the nonce of the sender account. In the yellow paper the account nonce is the first item in the state.

Word # in stack/ stack item no. initial stack bytes
1 v 0
2 r 32
3 s 64
4 nonce 96
5 to 128
6 value 160
7 gasprice 192
8 data 224

Addresses are 160 bits, but above it sets aside 32 bytes, but I guess it does that for efficiency with extracting it, rather than performing bitwise operation on a word, where other data is stored in the word.

This comment has been minimized.

@holiman

holiman Oct 6, 2017

Contributor

In the context of this EIP, the nonce is not the same nonce as the YP talks about. The EVM has a 'native' nonce per account, whereas in the context of this EIP, the nonce is counter within the state.

@holiman

holiman Oct 6, 2017

Contributor

In the context of this EIP, the nonce is not the same nonce as the YP talks about. The EVM has a 'native' nonce per account, whereas in the context of this EIP, the nonce is counter within the state.

This comment has been minimized.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

Ah OK, it's like the sequence number that Vitalik referred to in EIP 101. #28

@jamesray1

jamesray1 Oct 6, 2017

Contributor

Ah OK, it's like the sequence number that Vitalik referred to in EIP 101. #28

Show outdated Hide outdated EIPS/abstraction.md
tx_data = string(~calldatasize() - 224)
~calldataload(tx_data, 224, ~calldatasize())
# Get signing hash
signing_data = string(~calldatasize() - 64)

This comment has been minimized.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

Just trying to understand this line with why it uses - 64. Signing data is passed into SHA3 below, which takes an arbitrary byte array loaded from a tuple of the first item in memory to the sum of the first and second items, minus 1, as follows:

screenshot from 2017-10-06 16-23-41

~calldatasize() returns in this case a byte array of minimum length 224 bytes, plus the arbitrary length input data field.

So for signing the data I presume that there are two words that aren't needed from the input data fields, although it's not clear to me immediately from reading what they are. The purpose is to abstract out the security model, so v, r, and s then don't seem to be needed; i.e. leave the security model to be defined externally.

However, ~calldatasize just returns the size of the input data, rather than copying it. So this line doesn't seem to make sense when the variable it evaluates to, signing_data, is passed into SHA3. You could have two input data that are the same size with different data that when passed into SHA3 will return the same hash.

So wouldn't it make more sense to copy the input data, except for v, r and s (presuming that these are the three fields, rather than two as specified, that don't need to be copied) into signing_data?

More info: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm

@jamesray1

jamesray1 Oct 6, 2017

Contributor

Just trying to understand this line with why it uses - 64. Signing data is passed into SHA3 below, which takes an arbitrary byte array loaded from a tuple of the first item in memory to the sum of the first and second items, minus 1, as follows:

screenshot from 2017-10-06 16-23-41

~calldatasize() returns in this case a byte array of minimum length 224 bytes, plus the arbitrary length input data field.

So for signing the data I presume that there are two words that aren't needed from the input data fields, although it's not clear to me immediately from reading what they are. The purpose is to abstract out the security model, so v, r, and s then don't seem to be needed; i.e. leave the security model to be defined externally.

However, ~calldatasize just returns the size of the input data, rather than copying it. So this line doesn't seem to make sense when the variable it evaluates to, signing_data, is passed into SHA3. You could have two input data that are the same size with different data that when passed into SHA3 will return the same hash.

So wouldn't it make more sense to copy the input data, except for v, r and s (presuming that these are the three fields, rather than two as specified, that don't need to be copied) into signing_data?

More info: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm

Show outdated Hide outdated EIPS/abstraction.md
prev_nonce = ~sload(-1)
assert tx_nonce == prev_nonce + 1
assert self.balance >= tx_value + tx_gasprice * tx.startgas
assert ~ecrecover(signing_hash, sig_v, sig_r, sig_s) == <pubkey hash here>

This comment has been minimized.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

Should we also abstract the pubkey verification? It could even be abstracted internally, by having a number of precompile contracts where you can call one with an opcode sigVerify. The opcode could even have a default option (where you can call it without any argument). However, I guess that there is not as much benefit to abstract the signature verification algorithm compared to abstracting the signature generation algorithm.

@jamesray1

jamesray1 Oct 6, 2017

Contributor

Should we also abstract the pubkey verification? It could even be abstracted internally, by having a number of precompile contracts where you can call one with an opcode sigVerify. The opcode could even have a default option (where you can call it without any argument). However, I guess that there is not as much benefit to abstract the signature verification algorithm compared to abstracting the signature generation algorithm.

@jamesray1

This comment has been minimized.

Show comment
Hide comment
@jamesray1

jamesray1 Oct 20, 2017

Contributor

Should we include EIP 86 in the title?

Contributor

jamesray1 commented Oct 20, 2017

Should we include EIP 86 in the title?

@cdetrio

This comment has been minimized.

Show comment
Hide comment
@cdetrio

cdetrio Dec 19, 2017

Member

Discussion of account abstraction proposals has continued here https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263

Member

cdetrio commented Dec 19, 2017

Discussion of account abstraction proposals has continued here https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Mar 23, 2018

Collaborator

This EIP is mentioned as an example EIP in EIP-1. Can we merge it as a draft? @vbuterin, can you add the copyright assignment clause, please?

Collaborator

Arachnid commented Mar 23, 2018

This EIP is mentioned as an example EIP in EIP-1. Can we merge it as a draft? @vbuterin, can you add the copyright assignment clause, please?

Arachnid and others added some commits Mar 25, 2018

Merge pull request #947 from ethereum/vbuterin-patch-3-patch
Rename abstraction.md to eip-86.md, add copyright clause, fix header.

@Arachnid Arachnid merged commit 64f6248 into master Mar 27, 2018

0 of 2 checks passed

continuous-integration/travis-ci/push The Travis CI build failed
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details

@Arachnid Arachnid deleted the vbuterin-patch-3 branch Mar 27, 2018

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Mar 27, 2018

Collaborator

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

  • Frontmatter is now contained between lines with only a triple dash ('---')
  • Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---
Collaborator

Arachnid commented Mar 27, 2018

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

  • Frontmatter is now contained between lines with only a triple dash ('---')
  • Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

johnhforrest added a commit to codex-protocol/EIPs that referenced this pull request Mar 27, 2018

Abstraction of transaction origin and signature.md (#208)
* Create abstraction.md

Implements a set of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Rename abstraction.md to eip-86.md, add copyright clause, fix header.

Arachnid added a commit to Arachnid/EIPs that referenced this pull request Mar 27, 2018

Abstraction of transaction origin and signature.md (#208)
* Create abstraction.md

Implements a set of changes that serve the combined purpose of "abstracting out" signature verification and nonce checking, allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Update abstraction.md

* Rename abstraction.md to eip-86.md, add copyright clause, fix header.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment