Abstraction of transaction origin and signature.md #208

vbuterin · 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.

cdetrio · Feb 25, 2017

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

pirapira · 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 · Mar 1, 2017

@yann300 is also working on this.

pirapira · Mar 2, 2017

pirapira reviewed Mar 2, 2017

View changes

pirapira · Mar 2, 2017

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

gumb0 · Mar 13, 2017

gumb0 reviewed Mar 13, 2017

View changes

gumb0 · Mar 13, 2017

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

chriseth · Mar 21, 2017

chriseth reviewed Mar 21, 2017

View changes

chriseth · Mar 21, 2017

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 · Mar 21, 2017

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 · 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 · Mar 21, 2017

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 · 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 · 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 · Mar 21, 2017

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

winsvega · Mar 21, 2017

So anyone will be able to create contracts for free?

pirapira · 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 · Mar 21, 2017

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

chriseth · 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 · Mar 21, 2017

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

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

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

pirapira · 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 · 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 · 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.

jimpo · Sep 20, 2017

jimpo reviewed Sep 20, 2017

View changes

jimpo · Sep 20, 2017

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.


Is + uint256 addition or concatenation?

jamesray1 · Oct 6, 2017

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 · Oct 6, 2017

EIPS/abstraction.md

+tx_nonce = ~calldataload(96)
+tx_to = ~calldataload(128)
+tx_value = ~calldataload(160)
+tx_gasprice = ~calldataload(192)


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.

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.

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.

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 · Oct 6, 2017

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 · Oct 6, 2017

EIPS/abstraction.md

+
+```python
+# Get signature from tx data
+sig_v = ~calldataload(0)


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 · Oct 6, 2017

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 · Oct 6, 2017

EIPS/abstraction.md

+~calldataload(signing_data + 32, 96, ~calldatasize() - 96)
+signing_hash = sha3(signing_data:str)
+# Perform usual checks
+prev_nonce = ~sload(-1)


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

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.

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

jamesray1 · Oct 6, 2017

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 · Oct 6, 2017

EIPS/abstraction.md

+tx_data = string(~calldatasize() - 224)
+~calldataload(tx_data, 224, ~calldatasize())
+# Get signing hash
+signing_data = string(~calldatasize() - 64)


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:

~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 · Oct 6, 2017

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 · Oct 6, 2017

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 · Oct 20, 2017

Should we include EIP 86 in the title?

cdetrio · Dec 19, 2017

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

Arachnid · 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 · Mar 27, 2018

Arachnid approved these changes Mar 27, 2018

View changes

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

arkpar referenced this pull request Feb 27, 2017
Merged
EIP-86 #4697

This was referenced Mar 1, 2017

Closed

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

Open

Proposed initial abstraction changes for Metropolis #86

arkpar referenced this pull request Mar 9, 2017
Closed
Byzantium release #4833
12 of 12 tasks complete

vbuterin referenced this pull request Mar 21, 2017
Open
New transaction formats #232

sorpaas referenced this pull request Sep 3, 2017
Open
ECIP-? Atomic Transactions #40

MicahZoltu referenced this pull request Sep 28, 2017
Closed
Design Security: Do not constrain users to non-contracts or freeze tokens for extended periods of time. #9

catageek referenced this pull request Nov 28, 2017
Open
Add web3.eth.encrypt method for RPC & web3 #130

MitchK referenced this pull request Jan 5, 2018
Open
Idea: Making transaction nonce checking more flexible #822

spalladino referenced this pull request Jan 31, 2018
Open
Scheduler feature idea: gas-free token transactions #12

Arachnid added the needs-merge label Mar 23, 2018

Arachnid merged commit 64f6248 into master Mar 27, 2018
0 of 2 checks passed

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 deleted the vbuterin-patch-3 branch Mar 27, 2018

vietlq referenced this pull request Apr 6, 2018
Open
Check EIP86 and other related to "abstract account" #2

changwu-tw referenced this pull request Apr 10, 2018
Open
Using NULL_SENDER tx to send vote tx #6

starmanzz9 referenced this pull request Apr 23, 2018
Closed
Sending value in a contract creation #313

szerintedmi referenced this pull request Apr 29, 2018
Closed
Transferring A-EUR without ETH #84

cdetrio referenced this pull request Jun 18, 2018
Open
Account abstraction for main chain #859

gumb0 referenced this pull request Jul 23, 2018
Closed
Implement Skinny CREATE2 opcode #5119

holiman referenced this pull request Sep 17, 2018
Closed
Ethereum Core Devs Meeting 46 Agenda #56

ethereum/EIPs

Join GitHub today

Abstraction of transaction origin and signature.md #208

Conversation

vbuterin commented Feb 10, 2017

This comment has been minimized.

cdetrio commented Feb 25, 2017

arkpar referenced this pull request Feb 27, 2017

This was referenced Mar 1, 2017

This comment has been minimized.

pirapira commented Mar 1, 2017 • edited

This comment has been minimized.

pirapira commented Mar 1, 2017

pirapira reviewed Mar 2, 2017 View changes

This comment has been minimized.

This comment has been minimized.

rphmeier commented Mar 7, 2017 • edited

arkpar referenced this pull request Mar 9, 2017

gumb0 reviewed Mar 13, 2017 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

gumb0 Apr 28, 2017 • edited

This comment has been minimized.

This comment has been minimized.

winsvega commented Mar 17, 2017 • edited

chriseth reviewed Mar 21, 2017 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

chriseth commented Mar 21, 2017

This comment has been minimized.

vbuterin commented Mar 21, 2017 • edited

This comment has been minimized.

pirapira commented Mar 21, 2017 • edited

This comment has been minimized.

winsvega commented Mar 21, 2017 • edited

This comment has been minimized.

chriseth commented Mar 21, 2017

This comment has been minimized.

winsvega commented Mar 21, 2017

This comment has been minimized.

pirapira commented Mar 21, 2017

This comment has been minimized.

winsvega commented Mar 21, 2017

This comment has been minimized.

chriseth commented Mar 21, 2017

This comment has been minimized.

winsvega commented Mar 21, 2017 • edited

This comment has been minimized.

chriseth commented Mar 21, 2017

This comment has been minimized.

pirapira commented Mar 21, 2017

This comment has been minimized.

winsvega commented Mar 21, 2017 • edited

This comment has been minimized.

pirapira commented Mar 21, 2017

vbuterin referenced this pull request Mar 21, 2017

This comment has been minimized.

vbuterin commented Mar 21, 2017

This comment has been minimized.

tomusdrw commented Mar 23, 2017 • edited

sorpaas referenced this pull request Sep 3, 2017

jimpo reviewed Sep 20, 2017 View changes

This comment has been minimized.

jimpo Sep 20, 2017 • edited

MicahZoltu referenced this pull request Sep 28, 2017

jamesray1 reviewed Oct 6, 2017 View changes

This comment has been minimized.

jamesray1 Oct 6, 2017 • edited

This comment has been minimized.

This comment has been minimized.

jamesray1 Oct 6, 2017 • edited

jamesray1 reviewed Oct 6, 2017 View changes

This comment has been minimized.

jamesray1 reviewed Oct 6, 2017 View changes

This comment has been minimized.

jamesray1 Oct 6, 2017 • edited

pirapira commented Mar 1, 2017 •

edited

pirapira reviewed Mar 2, 2017

View changes

rphmeier commented Mar 7, 2017 •

edited

gumb0 reviewed Mar 13, 2017

View changes

gumb0 Apr 28, 2017 •

edited

winsvega commented Mar 17, 2017 •

edited

chriseth reviewed Mar 21, 2017

View changes

vbuterin commented Mar 21, 2017 •

edited

pirapira commented Mar 21, 2017 •

edited

winsvega commented Mar 21, 2017 •

edited

winsvega commented Mar 21, 2017 •

edited

winsvega commented Mar 21, 2017 •

edited

tomusdrw commented Mar 23, 2017 •

edited

jimpo reviewed Sep 20, 2017

View changes

jimpo Sep 20, 2017 •

edited

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 Oct 6, 2017 •

edited

jamesray1 Oct 6, 2017 •

edited

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 Oct 6, 2017 •

edited

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 Oct 6, 2017 •

edited

jamesray1 reviewed Oct 6, 2017

View changes

jamesray1 Oct 6, 2017 •

edited

Arachnid approved these changes Mar 27, 2018

View changes

Arachnid merged commit `64f6248` into master Mar 27, 2018
0 of 2 checks passed