Publish EIP-67 as withdrawn

EIPS/eip-67.md

@@ -0,0 +1,80 @@
+---
+eip: 67
+title: URI Scheme with Metadata, Value and Bytecode
+description: Format for encoding transactions into a URI
+author: Alex Van de Sande (@alexvansande)
+discussions-to: https://github.com/ethereum/EIPs/issues/67
+status: Withdrawn
+type: Standards Track
+category: ERC
+created: 2016-02-17
+withdrawal-reason: Superseded by EIP-681
+---
+
+## Abstract
+
+This proposal (inspired by BIP 21) defines a format for encoding a transaction into a URI, including a recipient, number of ethers (possibly zero), and optional bytecode.
+
+## Motivation
+
+Imagine these scenarios:
+
+    * An exchange or a instant converter like ShapeShift wants to create a single Ethereum address for payments that will be converted into credit in their internal system or output bitcoin to an address.
+    * A store wants to show a QR code to a client that will pop up a payment for exactly 12.34 ethers, which contains metadata on the product being bought.
+    * A betting site wants to provide a link that the user can click on his site and it will open a default Ethereum wallet and execute a specific contract with given parameters.
+    * A dapp in Mist wants to simply ask the user to sign a transaction with a specific ABI in a single call.
+
+
+In all these scenarios, the provider wants to internally set up a transaction, with a recipient, an associated number of ethers (or none) and optional bytecode, all without requiring any fuss from the end user that is expected simply to choose a sender and authorise the transaction.
+
+Currently implementations for this are wonky: ShapeShift creates tons of temporary addresses and uses an internal system to check which one correspond to which metadata, there isn't any standard way for stores that want payment in ether to put specific metadata about price on the call and any app implementing contracts will have to use different solutions depending on the client they are targeting.
+
+The proposal goes beyond address, and also includes optional bytecode and value. Of course this would make the link longer, but it should not be something visible to the user. Instead it should be shown as a visual code (QR or otherwise), a link, or some other way to pass the information.
+
+If properly implemented in all wallets, this should make execution of contracts directly from wallets much simpler as the wallet client only needs to put the bytecode obtained by reading the QR code.
+
+## Specification
+
+If we follow the bitcoin standard, the result would be:
+
+```
+ ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?data=<bytecode>]
+```
+
+Other data could be added, but ideally the client should take them from elsewhere in the blockchain, so instead of having a `label` or a `message` to be displayed to the users, these should be read from an identity system or metadata on the transaction itself.
+
+### Example 1
+
+Clicking this link would open a transaction that would try to send _5 unicorns_ to address _deadbeef_. The user would then simply approve, based on each wallet UI.
+
+```
+ ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&data=0xa9059cbb00000000000000000000000000000000000000000000000000000000deadbeef0000000000000000000000000000000000000000000000000000000000000005
+```
+
+#### Without Bytecode
+
+Alternatively, the bytecode could be generated by the client and the request would be in plain text:
+
+```
+ ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?function=nameOfFunction(param)]
+```
+
+### Example 2
+
+This is the same function as above, to send 5 unicorns from he sender to _deadbeef_, but now with a more readable function, which the client converts to bytecode.
+
+```
+ ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&function=transfer(address 0xdeadbeef, uint 5)
+```
+
+## Rationale
+
+TODO
+
+## Security Considerations
+
+TODO
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).