Abstraction of transaction origin and signature.md #208

vbuterin · 2017-02-10T17:38:03Z

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 · 2017-02-25T11:24:12Z

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

pirapira · 2017-03-01T15:02:29Z

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 · 2017-03-01T15:03:26Z

@yann300 is also working on this.

pirapira · 2017-03-02T09:30:36Z

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.


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

rphmeier · 2017-03-07T18:20:23Z

@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

gumb0 · 2017-03-13T10:28:47Z

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`


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?

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.

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?

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 · 2017-03-17T20:31:23Z

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?

chriseth · 2017-02-16T12:29:40Z

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 is not formatted correctly.

How? I'm not seeing anything wrongly formatted https://github.com/ethereum/EIPs/blob/4120d2180a1cf62151066d9fb16742867315d649/EIPS/abstraction.md#specification

chriseth · 2017-02-16T12:31:37Z

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]))`


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.

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 · 2017-03-21T10:41:52Z

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 · 2017-03-21T10:44:13Z

So there are two paths to resolving this:

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.
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 · 2017-03-21T10:51:03Z

@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 · 2017-03-21T10:51:08Z

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 · 2017-03-21T10:58:50Z

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

winsvega · 2017-03-21T11:00:14Z

So anyone will be able to create contracts for free?

pirapira · 2017-03-21T11:03:16Z

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

winsvega · 2017-03-21T11:14:48Z

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

chriseth · 2017-03-21T11:17:57Z

@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 · 2017-03-21T11:26:17Z

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

chriseth · 2017-03-21T11:32:14Z

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 · 2017-03-21T11:55:19Z

@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 · 2017-03-21T12:02:04Z

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

the nonce checking
the gasLimit/gasPrice charge/checking
the value transfer (allow/disallow)
contract creation

pirapira · 2017-03-21T12:28:11Z

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 · 2017-03-21T13:08:11Z

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 · 2017-03-23T22:04:21Z

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.

jamesray1 · 2017-10-06T07:27:32Z

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>


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 · 2017-10-20T03:36:53Z

Should we include EIP 86 in the title?

cdetrio · 2017-12-19T15:01:52Z

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

Arachnid · 2018-03-23T15:52:10Z

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?

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

Arachnid · 2018-03-27T15:11:43Z

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

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

Taylorman3 · 2023-08-17T02:37:01Z

So, one use case not being described either in the document or in any of the comments so far is improving the atomicity control over an ecdsa account's direct operations. Suppose I want to transfer an ENS domain "awesome.eth" (currently controlled by an ecdsa key) to the ecdsa account resolved by "vitalik.eth" . From a security model perspective, this is very easy to do safely. First, my client software resolves vitalik.eth, and then it builds a transaction that calls the appropriate ENS contracts, passing in that address as a new owner. Then I sign it and send it, right? But this actually has poor atomicity, because between the time I resolve vitalik.eth and when I send the transaction, the ecdsa account it points to may have been stolen, and the owner of vitalik.eth may have had to point it somewhere else (or any number of other things may have caused a valid and relevant repointing), in which case I am accidentally transferring awesome.eth to an address which the properly updated vitalik.eth registration no longer resolves to. A contract has no such problem, because it can atomically resolve-and-then-send in two consecutive operations that both have it as the msg.sender, with a complete guarantee that the destination has not changed since the first call. An EOA could use a forwarding contract to do both of these operations for it, except that in this example the EOA account is the owner of awesome.eth and using a forwarder would change the msg.sender (because an EOA cannot use delegatecall when calling the forwarding contract). In terms of atomicity, ecdsa accounts are currently second class citizens compared to contracts, and there's no reason for this other than limitations of the current transaction format (in particular, the inability to use delegatecall from an EOA). This is only one of many use cases that suffer in the current model with respect to atomicity (hardware wallets that want to the user to visually confirm important details are particularly hard hit for no inherent security model reason, to give one example).

So the question is: post EIP 208 do we expect even ECDSA users to move over to a new ecdsa-verifying contract to solve their atomicity woes? If so it is extremely important that tx.origin be changed to point to the contract of origin, or almost any existing use of tx.origin will break when that transition occurs (in the most abstract we can say that the purpose of tx.origin is to answer the question "which master puppeteer is causing all of this to happen, regardless of who the latest link in the chain was", and there are certainly a ton of valid use cases for that). Even aside from that I think that removing the current ability to answer that question is a significant step backward.

arkpar mentioned this pull request Feb 27, 2017

EIP-86 openethereum/parity-ethereum#4697

Merged

This was referenced Mar 1, 2017

[consensus uncertain] EIP86: initial account abstraction ethereum/yellowpaper#249

Closed

Proposed initial abstraction changes for Metropolis #86

Closed

pirapira reviewed Mar 2, 2017

View reviewed changes

arkpar mentioned this pull request Mar 9, 2017

Byzantium release openethereum/parity-ethereum#4833

Closed

12 tasks

gumb0 reviewed Mar 13, 2017

View reviewed changes

chriseth reviewed Mar 21, 2017

View reviewed changes

vbuterin mentioned this pull request Mar 21, 2017

New transaction formats #232

Closed

jamesray1 reviewed Oct 6, 2017

View reviewed changes

catageek mentioned this pull request Nov 28, 2017

Add web3.eth.encrypt method for RPC & web3 #130

Closed

MitchK mentioned this pull request Jan 5, 2018

Idea: Making transaction nonce checking more flexible #822

Closed

spalladino mentioned this pull request Jan 31, 2018

Scheduler feature idea: gas-free token transactions OpenZeppelin/openzeppelin-labs#12

Open

Arachnid added the needs-merge label Mar 23, 2018

Arachnid and others added 2 commits March 25, 2018 18:00

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

6ea5732

Merge pull request #947 from ethereum/vbuterin-patch-3-patch

fd171bb

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

Arachnid approved these changes Mar 27, 2018

View reviewed changes

Arachnid merged commit 64f6248 into master Mar 27, 2018

Arachnid deleted the vbuterin-patch-3 branch March 27, 2018 14:34

vietlq mentioned this pull request Apr 6, 2018

Check EIP86 and other related to "abstract account" vietlq/enki-login#2

Open

changwu-tw mentioned this pull request Apr 10, 2018

Using NULL_SENDER tx to send vote tx ethereum/docker-pyeth-dev#6

Open

starmanzz9 mentioned this pull request Apr 23, 2018

Sending value in a contract creation ethereumbook/ethereumbook#313

Closed

szerintedmi mentioned this pull request Apr 29, 2018

Transferring A-EUR without ETH Augmint/augmint-contracts#84

Closed

cdetrio mentioned this pull request Jun 18, 2018

Account abstraction for main chain #859

Closed

gumb0 mentioned this pull request Jul 23, 2018

Implement Skinny CREATE2 opcode ethereum/aleth#5119

Closed

holiman mentioned this pull request Sep 17, 2018

Ethereum Core Devs Meeting 46 Agenda ethereum/pm#56

Closed

BitcoinOutput mentioned this pull request Oct 18, 2024

[Snyk] Fix for 1 vulnerabilities BitcoinOutput/EIPs#91

Open

Abstraction of transaction origin and signature.md #208

Abstraction of transaction origin and signature.md #208

Conversation

vbuterin commented Feb 10, 2017

cdetrio commented Feb 25, 2017

pirapira commented Mar 1, 2017 • edited Loading

pirapira commented Mar 1, 2017

Choose a reason for hiding this comment

rphmeier commented Mar 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gumb0 Apr 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

winsvega commented Mar 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chriseth commented Mar 21, 2017

vbuterin commented Mar 21, 2017 • edited Loading

pirapira commented Mar 21, 2017 • edited Loading

winsvega commented Mar 21, 2017 • edited Loading

chriseth commented Mar 21, 2017

winsvega commented Mar 21, 2017

pirapira commented Mar 21, 2017

winsvega commented Mar 21, 2017

chriseth commented Mar 21, 2017

winsvega commented Mar 21, 2017 • edited Loading

chriseth commented Mar 21, 2017

pirapira commented Mar 21, 2017

winsvega commented Mar 21, 2017 • edited Loading

pirapira commented Mar 21, 2017

vbuterin commented Mar 21, 2017

tomusdrw commented Mar 23, 2017 • edited Loading

jamesray1 Oct 6, 2017 • edited Loading

Choose a reason for hiding this comment

jamesray1 commented Oct 20, 2017

cdetrio commented Dec 19, 2017

Arachnid commented Mar 23, 2018

Arachnid commented Mar 27, 2018

Taylorman3 commented Aug 17, 2023

pirapira commented Mar 1, 2017 •

edited

Loading

rphmeier commented Mar 7, 2017 •

edited

Loading

gumb0 Apr 28, 2017 •

edited

Loading

winsvega commented Mar 17, 2017 •

edited

Loading

vbuterin commented Mar 21, 2017 •

edited

Loading

pirapira commented Mar 21, 2017 •

edited

Loading

winsvega commented Mar 21, 2017 •

edited

Loading

winsvega commented Mar 21, 2017 •

edited

Loading

winsvega commented Mar 21, 2017 •

edited

Loading

tomusdrw commented Mar 23, 2017 •

edited

Loading

jamesray1 Oct 6, 2017 •

edited

Loading