Deprecate HTTP(S) Transactions

text/0000-deprecate-http-tx.md

@@ -0,0 +1,109 @@
+- Title: Deprecate HTTP(S) Transactions
+- Authors: [joltz](mailto:joltz@protonmail.com)
+- Start date: April 28 2020
+- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000)
+- Tracking issue: [Edit if merged with link to tracking github issue]
+
+---
+
+# Summary
+[summary]: #summary
+
+Deprecating HTTP(S) as a transaction method helps preserve privacy for Grin users during the slate exchange process while building transactions. By only allowing the http listener in `grin-wallet` to listen on localhost by default, users and services will be encouraged to use more privacy-friendly transaction methods like Tor or directly exchanging armored slates. This improves privacy for the Grin ecosystem by ensuring that services do not force Grin users into transaction methods that can easily violate their privacy like HTTP(S).
+
+# Motivation
+[motivation]: #motivation
+
+Deprecating HTTP(S) provides a few benefits:
+  - User experience is improved by not having to manage firewall settings like port forwarding to accept Grin transactions from most users
+  - Wallet developer experience is improved with the need to support fewer transaction methods
+  - Users will no longer be encouraged to engage in transaction methods that potentially violate privacy during the transaction building process
+  - The ecosystem can converge around a universally accepted transaction flow that is privacy preserving
+
+The overall expected outcome is a privacy improvement for users that may otherwise have to reveal their IP address to send or receive Grin.
+
+# Community-level explanation
+[community-level-explanation]: #community-level-explanation
+
+Previously, Grin slates could be exchanged over HTTP(S) as a convenient method to take the required steps to exchange slate data between wallets to build a transaction. This method was commonly adopted by exchanges and services who already had infrastructure in place to configure wallets to listen for incoming HTTPS requests.
+
+Unfortunately, while convenient, this method of exchange requires the sender and receiver to reveal their IP addresses to route the network packets. This is bad for user privacy because without taking extra obfuscating steps, an IP address can often be traced to an individual.
+
+While steps can be taken to obfuscate a users true IP (like using a VPN), it is undesirable for a privacy-preserving technology like Grin to rely on this method for conventional use. It does not seem natural for users that are concerned about their privacy enough to use a technology like Grin to at the same time accept that their IP address is revealed when exchanging Grin with many services.
+
+Deprecating HTTP(S) means that the old method of sending and listening for transactions over traditional HTTP(S) is no longer supported to help preserve privacy for Grin users who may not be aware of the risk to privacy using HTTP(S) poses.
+
+This reduces the overall number of transaction transport methods that need to be supported but requires that all services and wallets that previously only accepted/sent HTTP(S) transactions to upgrade at least to the version this RFC is implemented in to support their users.
+
+For the average user this means that to send or receive Grin they can use the Tor method, armored slate string exchange or file exchange. It is no longer possible to send and receive Grin via the HTTP(S) method without custom configuration.
+
+For wallet developers, it is no longer necessary to be concerned about managing HTTP(S) endpoints. All transactions will be conducted via Tor or asynchronous exchange of armored slate strings or files. It can no longer be assumed that the counterparty in the transaction supports HTTP(S).
+
+Previously, some services like exchanges _only_ supported HTTP(S) Grin transactions. This change impacts these services significantly.
+
+Tor is the closest replacement to HTTP(S), but for some services the use of Tor is unacceptable. These services will will need to refactor the user flow to allow supporting armored slate strings instead, as the HTTP(S) method is no longer supported by default for `grin-wallet`.
+
+This up-front cost should be worth the reduced complexity required in supporting the alternative transaction methods as well as the privacy benefits provided to the users of the services.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+The technical and implementation details for this RFC are simple: no new features are added and some existing features are restricted:
+
+- `grin-wallet` http listener only accepts connections from localhost
+
+- `grin-wallet listen` no longer accepts `-e` argument
+
+- `grin-wallet send -d` provides a strong warning if the destination is not a valid .onion address
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+- Forces changes to existing transaction building workflows that use HTTP(S)
+
+- Remaining transaction options (Tor, armored slate, file) may not be appealing for services already exclusively using HTTP(S)
+
+- Forces "always on" wallet listeners to use Tor or to build out logic to support handling armored slates in the UX flow
+
+- Potentially makes a technology that is already challenging for services to adopt even more challenging to adopt
+
+- Those that do not value privacy as a first-order objective may see this as an unnecessary inconvenience
+
+- Friction could cause some services to avoid Grin completely rather than adding support for a new transaction method
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+Instead of looking for a best possible transaction method, this proposal comes down to favoring the least worst transaction methods by removing the worst transaction methods from the perspectives of privacy, security, censorship resistance and minimalism.
+
+In this case, HTTP(S) is the least desirable transaction method. It actively jeopardizes user privacy when services only accept payments via HTTP(S), can jeapardize security when not configured properly, is not censorship resistant as IPs can be blocked and domains can be seized and is not minimal once the additional configuration requirements are factored in.
+
+By not deprecating HTTP(S) we lose an opportunity to provide an additional layer of privacy to present and future Grin supporters. While there will likely be a fair amount of friction to the adoption of this RFC, most will agree it is something that will need to be done eventually and will only become more difficult to do with time.
+
+# Prior art
+[prior-art]: #prior-art
+
+Bitcoin previously used a similar transaction method (send to IP) which was deprecated as well for many valid reasons. While the arguments presented in this RFC are primarily derived from the objective of delivering privacy, there are other good reasons previously discussed in the context of Bitcoin. These discussions can be found partially in the [bitcointalk post](https://bitcointalk.org/index.php?topic=9334.0) accompanying the [PR](https://github.com/bitcoin/bitcoin/pull/253) that removed this feature for Bitcoin.
+
+Note that Grin is not quite in the same position as Bitcoin was when they deprecated this method as an alternative method existed that did not require interaction was available (P2PKH). Grin will still require interaction for the forseeable future, either directly via Tor or asynchronously via armored slate or file.
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+- Is it acceptable to the ecosystem to remove a commonly used transaction method?
+
+- Will the adoption of this RFC cause an unacceptable loss of support from existing adopting services?
+
+- Will deprecating HTTP(S) grow or reduce adoption in the next 6-12 months? 1-3 years? 5-10 years?
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+This RFC along with others can eventually support ecosystem convergence around a single acceptable transaction building workflow supported by all wallets and services.
+
+# References
+[references]: #references
+
+https://bitcointalk.org/index.php?topic=9334.0
+
+https://github.com/bitcoin/bitcoin/pull/253