From b0e2bb2943ab2152e22a98da5831d5cf6b9c95b0 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Fri, 10 Feb 2017 12:37:49 -0500 Subject: [PATCH 1/9] 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. --- EIPS/abstraction.md | 93 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 EIPS/abstraction.md diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md new file mode 100644 index 0000000000000..dac6292ece135 --- /dev/null +++ b/EIPS/abstraction.md @@ -0,0 +1,93 @@ +### Preamble + + EIP: + Title: Abstraction + Author: Vitalik Buterin + Type: Standard Track + Category: Core + Status: Draft + Created: 2017-02-10 + +### Summary + +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. + +### Parameters + +* METROPOLIS_FORK_BLKNUM: TBD +* CHAIN_ID: same as used for EIP 155 (ie. 1 for mainnet, 3 for testnet) +* NULL_SENDER: 2**160 - 1 + +### 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` +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. + +### Rationale + +The goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model. + +Under EIP 86, we can expect users to store their ether in contracts, whose code might look like the following (example in Serpent): + +```python +# Get signature from tx data +sig_v = ~calldataload(0) +sig_r = ~calldataload(32) +sig_s = ~calldataload(64) +# Get tx arguments +tx_nonce = ~calldataload(96) +tx_to = ~calldataload(128) +tx_value = ~calldataload(160) +tx_gasprice = ~calldataload(192) +tx_data = string(~calldatasize() - 224) +~calldataload(tx_data, 224, ~calldatasize()) +# Get signing hash +signing_data = string(~calldatasize() - 64) +~mstore(signing_data, tx.startgas) +~calldataload(signing_data + 32, 96, ~calldatasize() - 96) +signing_hash = sha3(signing_data:str) +# Perform usual checks +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) == +# Update nonce +~sstore(-1, prev_nonce + 1) +# Pay for gas +~send(MINER_CONTRACT, tx_gasprice * tx.startgas) +# Make the main call +~call(msg.gas - 50000, tx_to, tx_value, tx_data, len(tx_data), 0, 0) +# Get remaining gas payments back +~call(20000, MINER_CONTRACT, 0, [msg.gas], 32, 0, 0) +``` + +This can be thought of as a "forwarding contract". It accepts data from the "entry point" address 2**160 - 1 (an account that anyone can send transactions from), expecting that data to be in the format `[sig, nonce, to, value, gasprice, data]`. The forwarding contract verifies the signature, and if the signature is correct it sets up a payment to the miner and then sends a call to the desired address with the provided value and data. + +The benefits that this provides lie in the most interesting cases: + +- **Multisig wallets**: currently, sending from a multisig wallet requires each operation to be ratified by the participants, and each ratification is a transaction. This could be simplified by having one ratification transaction include signatures from the other participants, but even still it introduces complexity because the participants' accounts all need to be stocked up with ETH. With this EIP, it will be possible to just have the contract store the ETH, send a transaction containing all signatures to the contract directly, and the contract can pay the fees. +- **Ring signature mixers**: the way that ring signature mixers work is that N individuals send 1 coin into a contract, and then use a linkable ring signature to withdraw 1 coin later on. The linkable ring signature ensures that the withdrawal transaction cannot be linked to the deposit, but if someone attempts to withdraw twice then those two signatures can be linked and the second one prevented. However, currently there is a privacy risk: to withdraw, you need to have coins to pay for gas, and if these coins are not properly mixed then you risk compromising your privacy. With this EIP, you can pay for gas straight our of your withdrawn coins. +- **Custom cryptography**: users can upgrade to ed25519 signatures, Lamport hash ladder signatures or whatever other scheme they want on their own terms; they do not need to stick with ECDSA. +- **Non-cryptographic modifications**: users can require transactions to have expiry times (this being standard would allow old empty/dust accounts to be flushed from the state securely), use k-parallelizable nonces (a scheme that allows transactions to be confirmed slightly out-of-order, reducing inter-transaction dependence), or make other modifications. + +(2) and (3) introduce a feature similar to bitcoin's P2SH, allowing users to send funds to addresses that provably map to only one particular piece of code. Something like this is crucial in the long term because, in a world where all accounts are contracts, we need to preserve the ability to send to an account before that account exists on-chain, as that's a basic functionality that exists in all blockchain protocols today. + +### Miner and transaction replaying strategy + +Note that miners would need to have a strategy for accepting these transactions. This strategy would need to be very discriminating, because otherwise they run the risk of accepting transactions that do not pay them any fees, and possibly even transactions that have no effect (eg. because the transaction was already included and so the nonce is no longer current). + +One simple strategy is to have a set of regexps that the to address of an account would be checked against, each regexp corresponding to a "standard account type" which is known to be "safe" (in the sense that if an account has that code, and a particular check involving the account balances, account storage and transaction data passes, then if the transaction is included in a block the miner will get paid), and mine and relay transactions that pass these checks. + +One example would be to check as follows: + +1. Check that the to address has code which is the compiled version of the Serpent code above, with `` replaced with any public key hash. +2. Check that the signature in the transaction data verifies with that key hash. +3. Check that the gasprice in the transaction data is sufficiently high +4. Check that the nonce in the state matches the nonce in the transaction data +5. Check that there is enough ether in the account to pay for the fee + +If all five checks pass, relay and/or mine the transaction. + +A looser but still effective strategy would be to accept any code that fits the same general format as the above, consuming only a limited amount of gas to perform nonce and signature checks and having a guarantee that transaction fees will be paid to the miner. Another strategy is to, alongside other approaches, try to process any transaction that asks for less than 250,000 gas, and include it only if the miner's balance is appropriately higher after executing the transaction than before it. From 4120d2180a1cf62151066d9fb16742867315d649 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Fri, 24 Mar 2017 05:48:54 -0400 Subject: [PATCH 2/9] Update abstraction.md --- EIPS/abstraction.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md index dac6292ece135..8b856f27209da 100644 --- a/EIPS/abstraction.md +++ b/EIPS/abstraction.md @@ -1,7 +1,7 @@ ### Preamble EIP: - Title: Abstraction + Title: Abstraction of transaction origin and signature Author: Vitalik Buterin Type: Standard Track Category: Core @@ -22,8 +22,9 @@ Implements a set of changes that serve the combined purpose of "abstracting out" 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. +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. ### Rationale From 174d6a5ae428e37bc83a4251bb93b92d458fd2ff Mon Sep 17 00:00:00 2001 From: vbuterin Date: Fri, 28 Apr 2017 07:29:25 -0400 Subject: [PATCH 3/9] Update abstraction.md --- EIPS/abstraction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md index 8b856f27209da..0e7eef1ff23e6 100644 --- a/EIPS/abstraction.md +++ b/EIPS/abstraction.md @@ -23,8 +23,8 @@ Implements a set of changes that serve the combined purpose of "abstracting out" 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]))` -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. +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]))` +4. Create a new opcode at `0xfb`, `CREATE2`, 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. ### Rationale From 976a003aa85ac8267e03fc1dfaa9c1121abe7d8e Mon Sep 17 00:00:00 2001 From: vbuterin Date: Fri, 5 May 2017 10:47:12 -0400 Subject: [PATCH 4/9] Update abstraction.md --- EIPS/abstraction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md index 0e7eef1ff23e6..58755b52f85dc 100644 --- a/EIPS/abstraction.md +++ b/EIPS/abstraction.md @@ -22,9 +22,9 @@ Implements a set of changes that serve the combined purpose of "abstracting out" 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. +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]))` -4. Create a new opcode at `0xfb`, `CREATE2`, 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. +4. 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 `sender` is as a 20-. If a contract at that address already exists, fails and returns 0 as if the init code had run out of gas. ### Rationale From f5a508f12bb4e8b87c9e6e3e5e8afbd3b4781b85 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Fri, 5 May 2017 10:52:24 -0400 Subject: [PATCH 5/9] Update abstraction.md --- EIPS/abstraction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md index 58755b52f85dc..28b08df629389 100644 --- a/EIPS/abstraction.md +++ b/EIPS/abstraction.md @@ -24,7 +24,7 @@ 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]))` -4. 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 `sender` is as a 20-. If a contract at that address already exists, fails and returns 0 as if the init code had run out of gas. +4. 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. If a contract at that address already exists, fails and returns 0 as if the init code had run out of gas. ### Rationale From 3100749e6baf43b1dc1e0d20ea622a7ceaebedd5 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Tue, 9 May 2017 22:13:13 -0400 Subject: [PATCH 6/9] Update abstraction.md --- EIPS/abstraction.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md index 28b08df629389..bc20fc1c10c0d 100644 --- a/EIPS/abstraction.md +++ b/EIPS/abstraction.md @@ -24,7 +24,8 @@ 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]))` -4. 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. If a contract at that address already exists, fails and returns 0 as if the init code had run out of gas. +4. 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. +5. Add to _all_ contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code, the operation fails and returns 0 as if the init code had run out of gas. ### Rationale From 94be170f814a9ceadbf82a2728e568b26e713726 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Wed, 10 May 2017 01:36:05 -0400 Subject: [PATCH 7/9] Update abstraction.md --- EIPS/abstraction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md index bc20fc1c10c0d..d442cb4bfdd87 100644 --- a/EIPS/abstraction.md +++ b/EIPS/abstraction.md @@ -25,7 +25,7 @@ If `block.number >= METROPOLIS_FORK_BLKNUM`, then: 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]))` 4. 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. -5. Add to _all_ contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code, the operation fails and returns 0 as if the init code had run out of gas. +5. Add to _all_ contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code OR non-empty nonce, the operation fails and returns 0 as if the init code had run out of gas. If an account has empty code and nonce but nonempty balance, the creation operation may still succeed. ### Rationale From bd136e662fca4154787b44cded8d2a29b993be66 Mon Sep 17 00:00:00 2001 From: vbuterin Date: Thu, 6 Jul 2017 05:57:44 -0400 Subject: [PATCH 8/9] Update abstraction.md --- EIPS/abstraction.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/EIPS/abstraction.md b/EIPS/abstraction.md index d442cb4bfdd87..9777632cc34ea 100644 --- a/EIPS/abstraction.md +++ b/EIPS/abstraction.md @@ -23,9 +23,8 @@ Implements a set of changes that serve the combined purpose of "abstracting out" 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]))` -4. 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. -5. Add to _all_ contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code OR non-empty nonce, the operation fails and returns 0 as if the init code had run out of gas. If an account has empty code and nonce but nonempty balance, the creation operation may still succeed. +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. +4. Add to _all_ contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code OR non-empty nonce, the operation fails and returns 0 as if the init code had run out of gas. If an account has empty code and nonce but nonempty balance, the creation operation may still succeed. ### Rationale From 6ea57329296933bfb93de22d8b35db4137835c47 Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Sun, 25 Mar 2018 18:00:12 +0100 Subject: [PATCH 9/9] Rename abstraction.md to eip-86.md, add copyright clause, fix header. --- EIPS/{abstraction.md => eip-86.md} | 34 +++++++++++++++++------------- 1 file changed, 19 insertions(+), 15 deletions(-) rename EIPS/{abstraction.md => eip-86.md} (95%) diff --git a/EIPS/abstraction.md b/EIPS/eip-86.md similarity index 95% rename from EIPS/abstraction.md rename to EIPS/eip-86.md index 9777632cc34ea..0e5102d1ffbbb 100644 --- a/EIPS/abstraction.md +++ b/EIPS/eip-86.md @@ -1,24 +1,24 @@ -### Preamble - - EIP: - Title: Abstraction of transaction origin and signature - Author: Vitalik Buterin - Type: Standard Track - Category: Core - Status: Draft - Created: 2017-02-10 - -### Summary +``` +eip: 86 +title: Abstraction of transaction origin and signature +author: Vitalik Buterin +type: Standards Track +category: Core +status: Draft +created: 2017-02-10 +``` + +# Summary 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. -### Parameters +# Parameters * METROPOLIS_FORK_BLKNUM: TBD * CHAIN_ID: same as used for EIP 155 (ie. 1 for mainnet, 3 for testnet) * NULL_SENDER: 2**160 - 1 -### Specification +# 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` @@ -26,7 +26,7 @@ If `block.number >= METROPOLIS_FORK_BLKNUM`, then: 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. 4. Add to _all_ contract creation operations, including transactions and opcodes, the rule that if a contract at that address already exists and has non-empty code OR non-empty nonce, the operation fails and returns 0 as if the init code had run out of gas. If an account has empty code and nonce but nonempty balance, the creation operation may still succeed. -### Rationale +# Rationale The goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model. @@ -75,7 +75,7 @@ The benefits that this provides lie in the most interesting cases: (2) and (3) introduce a feature similar to bitcoin's P2SH, allowing users to send funds to addresses that provably map to only one particular piece of code. Something like this is crucial in the long term because, in a world where all accounts are contracts, we need to preserve the ability to send to an account before that account exists on-chain, as that's a basic functionality that exists in all blockchain protocols today. -### Miner and transaction replaying strategy +# Miner and transaction replaying strategy Note that miners would need to have a strategy for accepting these transactions. This strategy would need to be very discriminating, because otherwise they run the risk of accepting transactions that do not pay them any fees, and possibly even transactions that have no effect (eg. because the transaction was already included and so the nonce is no longer current). @@ -92,3 +92,7 @@ One example would be to check as follows: If all five checks pass, relay and/or mine the transaction. A looser but still effective strategy would be to accept any code that fits the same general format as the above, consuming only a limited amount of gas to perform nonce and signature checks and having a guarantee that transaction fees will be paid to the miner. Another strategy is to, alongside other approaches, try to process any transaction that asks for less than 250,000 gas, and include it only if the miner's balance is appropriately higher after executing the transaction than before it. + +# Copyright + +Copyright and related rights waived via CC0.