Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing draft EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing draft EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
* Create eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update eip-Reward-full-nodes-validating-tx.md
* Update and rename eip-Reward-full-nodes-validating-tx.md to eip-Reward-full-nodes-and-clients.md
* Update eip-Reward-full-nodes-and-clients.md
* Update eip-Reward-full-nodes-and-clients.md
* Update eip-Reward-full-nodes-and-clients.md
* Update eip-Reward-full-nodes-and-clients.md
* Update eip-Reward-full-nodes-and-clients.md
* Update eip-Reward-full-nodes-and-clients.md
* Quotes for Micah
* The amount of computation to validate a transaction will be the same as a miner...
* Add comments on Micah's suggestions and give further specification details
* Further commentary on transaction fee amount for full nodes vs miner tx fees
* Add "One problem with this is that a miner could run a full node validator using a different address with the same computer, and just cache the result of their execution and use it for the full node validator. I'm not sure how you would prevent this, but perhaps you could using IP address tracking (similarly asserting that the IP address of a full node validator isn't the same as the miner) which would add additional complexity to the protocol, but this could also be hacked with dynamic IPs and VPNs."
* he user agent would contain the information needed to send an amount of ETH to the full node and the client, which are the addresses of these parties and the amounts to add. I think full nodes would need to add to their set up to add the address to receive ETH after validating transactions. These fields could be read-only, or immutable, so that someone can't overwrite them with another address, thus preventing one possible attack.
* Add a missing T
* Update frontmatter
* Comment out implementation, add backwards incompatibility
* Update the specification, rewording and moving content
* Update the header, Test Cases and Implementation
* Update eip-Reward-full-nodes-and-clients.md
* Chamge the category to Core
* to be assigned => <to be assigned>
* discussions-to: https://gitter.im/ethereum/topics/topic/5ac8574227c509a774e7901a/eip-reward-full-nodes-and-clients
* Move around fields in the header
* Add an extra line to see if that will get the build to pass
* Assign eip number 908
* Rename eip-Reward-full-nodes-and-clients.md to eip-908.md
* ERC777 A New Advanced Token Standard
* ERC777: Add ERC777 Logo
* ERC777: Normalize EIP/ERC names
* ERC777: Spec for tokensToSend when burning tokens
* ERC777: Update official repository
* ERC777: Clarification and corrections
- Clarify unclear sections of the spec
- Fix typos and grammar mistakes
- Improve aesthetics of the text
* ERC777: Change terminology of the repo, small fix
- Don't refer to the repo as the official repo but the repo of the
reference implementation
- Fix a small typo in the AuthorizedOperator event
* ERC777: logo & release to public domain (CC0)
* ERC777: Use markdown not html & relative links
* ERC777: Adapt to new EIP template
* ERC777: Use solidity syntax and fix relative links
* ERC777: Add discussions-to link
* ERC777: Fix link in discussion-to
* ERC777: Fix image links
* ERC777: Fix eip type
* ERC777: Update header
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing draft EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
* ERC-820 Pseudo-introspection using a registry contract.
* Typos, links, and better explanation of Nicks deployment method
* Formating fix
* Email address
* solidity syntax highlight
* Adapt to new template for EIPs
* Discussions link added
* Fix link in discussion-to
* Type fixed
- Create `assets` folder
- Move existing EIPs (1, 107, 858) assets into the `assets` folder
- Update link to assets in EIPs 1, 107 and 858
- Describe the inclusion of assets for EIPs in `README.md`
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing draft EIP(s)
- The creator of this PR is listed as an author on all modified EIP(s)
- The build is passing
* Added initial ASIC-resistant EIP details
* Format fixed
* Format fixed
* Format fixed
* Format fixed
* Format fixed
* Grammar fixes
* Added mention of more invasive hash algorithm replacements
* Added mention of the single duplicate in 0x010001cf
* Adjusted language to remove speculation and focus on the purpose and motivation of this pull request
* Assigned EIP number and discussion URL, altered language to be more descriptive about the intention and risk. Removed unneeded Concensus/Block field changes.
* Clarified FNV rational, provided code for basic sanity FNV candidate analysis and FNV selection, grammar fixes
* initial submission of draft EIP for consideration
* EIP-884 correct spelling and add section on permissions management
* EIP-884 added oldHash
* EIP-884 changed getHash to hasHash and cleaned up grammar and spelling
* EIP-884 updates to wording
* EIR-884 added clarification on Delaware GCL vs Reg A+
* EIR-884 tweaks so the proposed code actually compiles
* EIP-884 simplified ownerAt and added requirement that a verified address that owns tokens can not be removed
* EIP-884 added link to reference implementation
* EIP-884 added notes on ERC721
* EIP-884 renamed document, removed references to Reg A+, and updated interface to include stock cancellation and reissuance.
* EIP-884 updated some documentation in the proposed interface
* EIP-884 added isHolder function to proposed interface
* EIP-884 moved to new frontmatter format
* EIP-884 removed 'requires' from metadata
* EIP-884 renamed file to match others
* Update social includes to link to repo, not org
* Add support for eip_validator by Makoto Inoue
* Fix external links in EIPs
* Change eip_validator to 0.3.0
* Fix dependency issues
* Update eip_validator to 0.3.4
* Add more condition on EIP input files
* Bump eip_validator to ignore invalid eip file format
* Fix EIP 86
- Fixed typo (operator to operators)
- Explicitly call out the implementation MUST support multiple operators per owner as implied by the comments
- Removed unnecessary throw from the dev instructions on setApprovalForAll
* 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.
I'm adding myself as an co-author of this EIP. Nick and Maurelian can vouch that I wrote a large part of this text and helped design the initial mechanisms
ligi
Nick Johnson
Joe Jordan
Nick Savers
James Ray
Jordi Baylina
David Stanfill
Jacques Dafflon
Yoichi Hirai
MattLongCT
Dave Sag
Greg Colvin
Dean Eigenmann
John Forrest
vbuterin
Felix Lange
Alex Van de Sande
Tobias Oberstein
winsvega
William Entriken
C. Brown
Fang
Maurelian
zaq1tomo
Rikard Hjort