From e02c9c6662823c1e8f04e5c921f544d7031d43f2 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Sun, 1 Sep 2019 21:48:23 -0400 Subject: [PATCH 1/5] Create 0000-online-transacting-via-tor.md --- text/0000-online-transacting-via-tor.md | 40 +++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 text/0000-online-transacting-via-tor.md diff --git a/text/0000-online-transacting-via-tor.md b/text/0000-online-transacting-via-tor.md new file mode 100644 index 0000000..bc5d7d7 --- /dev/null +++ b/text/0000-online-transacting-via-tor.md @@ -0,0 +1,40 @@ +# 0000-online-transacting-via-tor
+Title: online-transacting-via-tor
+Authors: DavidBurkett
+Start date: September 1, 2019
+ +# Summary +Describes a standardized addressing and communication protocol for building Grin transactions. +Wallets will attempt to connect to the recipient directly to build transactions over a TOR hidden service similar to how http(s) transaction building works today. +If the recipient is not online, or cannot be contacted directly, users have the option of falling back to an “offline” communication system where slates are encrypted and stored, for a limited period of time, by a subset(TBD) of nodes known as “relay nodes” (described in a future RFC). + +# Motivation +Grin is unique in that it requires the sender and receiver to interact in order to transact. This presents a lot of unique challenges that most coins don’t have to deal with. There are a number of different incompatible standards for sending and receiving, resulting in confusion and headaches for many users. The hope is that the addressing mechanism described here will become the new default method for sending and receiving, deprecating several less secure and less private methods in the process. + +# Description +## Community-level explanation +From an end-user perspective, there should no longer be a need to configure routers and firewalls to receive grins. Sending and receiving should feel like any other cryptocurrency, where a simple encoded address is all you need to share before receiving. No firewall or router configuration should be necessary. + +## Reference-level explanation +### Addressing +Onion addresses for TOR hidden services are generated from an ed25519 public key (32 bytes), and include a checksum and a version[1]. This provides an equivalent level of security as bitcoin addresses, and can be ephemeral or permanent, depending on the user’s needs. Grin addresses should be generated in the same way as TOR addresses, although we have the flexibility to decide whether we would like to encode them using base32 (like TOR), base58 (like Bitcoin), or even a far superior encoding based on emojis. +Although ed25519 is a different curve than used by the grin protocol, we can still use our HD wallets to generate deterministic ed25519 public keys (and therefore Grin addresses). We can decide to generate them from a special keychain path, or even using a different master seed [2], along with a KDF for converting those HD child keys to ed25519-compatible private keys. + +### TOR Hidden Services +TOR hidden services can be used to directly serve the existing foreign APIs. When configuring TOR (whether bundled with grin, or installed separately), you would just publish a hidden service and configure TOR to forward all traffic to port 3420. This means we can continue supporting http(s) sending/receiving with no disruption, though it’s advisable to avoid sending directly over http(s) asap.In future versions of Grin, we can stop allowing non-local connections to the foreign wallet APIs. + +# Drawbacks +Requires users to setup and configure TOR, or bundle it with Grin, which could be non-trivial, and could conflict with locally installed/running versions. + +# Unresolved questions +* How should we encode addresses? base32, base58, emoji, etc. +* How often should addresses change? Should users manually request a new address, or should they auto expire? Should we support multiple? + +# Future possibilities +The changes in this RFC lead the way for: +* Payment proofs +* Offline transacting via SBBS/Grinbox-style relay system. See “Offline Transactions” RFC + +# References +[1] https://github.com/torproject/torspec/blob/87698dc1c0fa4cf2186f180a636fc7ad1c5fb5fd/rend-spec-v3.txt#L2059-L2081 +[2] https://github.com/mimblewimble/grin/blob/d918c5fe84e859290c9d09f5cfc167ed41d27bff/keychain/src/extkey_bip32.rs#L122 From 9d01bc5ee0b209df726f45165f4aa2f0c0169af5 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Mon, 2 Sep 2019 04:21:08 -0400 Subject: [PATCH 2/5] Update 0000-online-transacting-via-tor.md --- text/0000-online-transacting-via-tor.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-online-transacting-via-tor.md b/text/0000-online-transacting-via-tor.md index bc5d7d7..70a55e9 100644 --- a/text/0000-online-transacting-via-tor.md +++ b/text/0000-online-transacting-via-tor.md @@ -4,8 +4,8 @@ Authors: DavidBurkett
Start date: September 1, 2019
# Summary -Describes a standardized addressing and communication protocol for building Grin transactions. -Wallets will attempt to connect to the recipient directly to build transactions over a TOR hidden service similar to how http(s) transaction building works today. +Describes a standardized addressing and communication protocol for building Grin transactions.

+Wallets will attempt to connect to the recipient directly to build transactions over a TOR hidden service similar to how http(s) transaction building works today.

If the recipient is not online, or cannot be contacted directly, users have the option of falling back to an “offline” communication system where slates are encrypted and stored, for a limited period of time, by a subset(TBD) of nodes known as “relay nodes” (described in a future RFC). # Motivation @@ -17,7 +17,7 @@ From an end-user perspective, there should no longer be a need to configure rout ## Reference-level explanation ### Addressing -Onion addresses for TOR hidden services are generated from an ed25519 public key (32 bytes), and include a checksum and a version[1]. This provides an equivalent level of security as bitcoin addresses, and can be ephemeral or permanent, depending on the user’s needs. Grin addresses should be generated in the same way as TOR addresses, although we have the flexibility to decide whether we would like to encode them using base32 (like TOR), base58 (like Bitcoin), or even a far superior encoding based on emojis. +Onion addresses for TOR hidden services are generated from an ed25519 public key (32 bytes), and include a checksum and a version[1]. This provides an equivalent level of security as bitcoin addresses, and can be ephemeral or permanent, depending on the user’s needs. Grin addresses should be generated in the same way as TOR addresses, although we have the flexibility to decide whether we would like to encode them using base32 (like TOR), base58 (like Bitcoin), or even a far superior encoding based on emojis.

Although ed25519 is a different curve than used by the grin protocol, we can still use our HD wallets to generate deterministic ed25519 public keys (and therefore Grin addresses). We can decide to generate them from a special keychain path, or even using a different master seed [2], along with a KDF for converting those HD child keys to ed25519-compatible private keys. ### TOR Hidden Services From 1623aaaee36257579e116266d48861a0096a25a6 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Mon, 2 Sep 2019 04:21:20 -0400 Subject: [PATCH 3/5] Update 0000-online-transacting-via-tor.md --- text/0000-online-transacting-via-tor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-online-transacting-via-tor.md b/text/0000-online-transacting-via-tor.md index 70a55e9..cdcfcd5 100644 --- a/text/0000-online-transacting-via-tor.md +++ b/text/0000-online-transacting-via-tor.md @@ -36,5 +36,5 @@ The changes in this RFC lead the way for: * Offline transacting via SBBS/Grinbox-style relay system. See “Offline Transactions” RFC # References -[1] https://github.com/torproject/torspec/blob/87698dc1c0fa4cf2186f180a636fc7ad1c5fb5fd/rend-spec-v3.txt#L2059-L2081 +[1] https://github.com/torproject/torspec/blob/87698dc1c0fa4cf2186f180a636fc7ad1c5fb5fd/rend-spec-v3.txt#L2059-L2081
[2] https://github.com/mimblewimble/grin/blob/d918c5fe84e859290c9d09f5cfc167ed41d27bff/keychain/src/extkey_bip32.rs#L122 From 13c5cd262ec175f2211d0f92a989037a409f37a3 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Wed, 4 Sep 2019 05:17:32 -0400 Subject: [PATCH 4/5] Update 0000-online-transacting-via-tor.md --- text/0000-online-transacting-via-tor.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-online-transacting-via-tor.md b/text/0000-online-transacting-via-tor.md index cdcfcd5..4ac2d09 100644 --- a/text/0000-online-transacting-via-tor.md +++ b/text/0000-online-transacting-via-tor.md @@ -6,7 +6,7 @@ Start date: September 1, 2019
# Summary Describes a standardized addressing and communication protocol for building Grin transactions.

Wallets will attempt to connect to the recipient directly to build transactions over a TOR hidden service similar to how http(s) transaction building works today.

-If the recipient is not online, or cannot be contacted directly, users have the option of falling back to an “offline” communication system where slates are encrypted and stored, for a limited period of time, by a subset(TBD) of nodes known as “relay nodes” (described in a future RFC). +If the recipient is not online, or cannot be contacted directly, users have the option of falling back to an asynchronous communication system where slates are encrypted and stored, for a limited period of time, by “relay nodes” (described in 0000-asynchronous-transacting-via-relays). # Motivation Grin is unique in that it requires the sender and receiver to interact in order to transact. This presents a lot of unique challenges that most coins don’t have to deal with. There are a number of different incompatible standards for sending and receiving, resulting in confusion and headaches for many users. The hope is that the addressing mechanism described here will become the new default method for sending and receiving, deprecating several less secure and less private methods in the process. @@ -33,7 +33,7 @@ Requires users to setup and configure TOR, or bundle it with Grin, which could b # Future possibilities The changes in this RFC lead the way for: * Payment proofs -* Offline transacting via SBBS/Grinbox-style relay system. See “Offline Transactions” RFC +* Offline transacting via SBBS/Grinbox-style relay system. See 0000-asynchronous-transacting-via-relays RFC # References [1] https://github.com/torproject/torspec/blob/87698dc1c0fa4cf2186f180a636fc7ad1c5fb5fd/rend-spec-v3.txt#L2059-L2081
From 3ea1ae9844b694aa9b8b9e890642b2d25323b265 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Fri, 29 Nov 2019 02:32:44 -0500 Subject: [PATCH 5/5] Addressing PR comments. --- text/0000-online-transacting-via-tor.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/text/0000-online-transacting-via-tor.md b/text/0000-online-transacting-via-tor.md index 4ac2d09..6fce219 100644 --- a/text/0000-online-transacting-via-tor.md +++ b/text/0000-online-transacting-via-tor.md @@ -6,7 +6,7 @@ Start date: September 1, 2019
# Summary Describes a standardized addressing and communication protocol for building Grin transactions.

Wallets will attempt to connect to the recipient directly to build transactions over a TOR hidden service similar to how http(s) transaction building works today.

-If the recipient is not online, or cannot be contacted directly, users have the option of falling back to an asynchronous communication system where slates are encrypted and stored, for a limited period of time, by “relay nodes” (described in 0000-asynchronous-transacting-via-relays). +This RFC does not cover the offline transacting problem. # Motivation Grin is unique in that it requires the sender and receiver to interact in order to transact. This presents a lot of unique challenges that most coins don’t have to deal with. There are a number of different incompatible standards for sending and receiving, resulting in confusion and headaches for many users. The hope is that the addressing mechanism described here will become the new default method for sending and receiving, deprecating several less secure and less private methods in the process. @@ -17,17 +17,16 @@ From an end-user perspective, there should no longer be a need to configure rout ## Reference-level explanation ### Addressing -Onion addresses for TOR hidden services are generated from an ed25519 public key (32 bytes), and include a checksum and a version[1]. This provides an equivalent level of security as bitcoin addresses, and can be ephemeral or permanent, depending on the user’s needs. Grin addresses should be generated in the same way as TOR addresses, although we have the flexibility to decide whether we would like to encode them using base32 (like TOR), base58 (like Bitcoin), or even a far superior encoding based on emojis.

-Although ed25519 is a different curve than used by the grin protocol, we can still use our HD wallets to generate deterministic ed25519 public keys (and therefore Grin addresses). We can decide to generate them from a special keychain path, or even using a different master seed [2], along with a KDF for converting those HD child keys to ed25519-compatible private keys. +Onion addresses for TOR hidden services are generated from an ed25519 public key (32 bytes), and include a checksum and a version[1]. This provides an equivalent level of security as bitcoin addresses, and can be ephemeral or permanent, depending on the user’s needs. Grin addresses should be generated and base32 encoded in the same way as TOR v3 addresses.

+Although ed25519 is a different curve than used by the grin protocol, we can still use our HD wallets to generate deterministic ed25519 public keys (and therefore Grin addresses). For account `m/0`, addresses will be generated using keychain paths `m/0/1/x`, for account `m/1`, addresses will be generated using `m/1/1/x`, etc. To generate addresses for a keychain path, we derive the private key in the usual way, but then blake2b hash the derived key to get the ed25519 secret key, which can then be used to calculate the public key and address. ### TOR Hidden Services TOR hidden services can be used to directly serve the existing foreign APIs. When configuring TOR (whether bundled with grin, or installed separately), you would just publish a hidden service and configure TOR to forward all traffic to port 3420. This means we can continue supporting http(s) sending/receiving with no disruption, though it’s advisable to avoid sending directly over http(s) asap.In future versions of Grin, we can stop allowing non-local connections to the foreign wallet APIs. # Drawbacks -Requires users to setup and configure TOR, or bundle it with Grin, which could be non-trivial, and could conflict with locally installed/running versions. +Requires users to setup TOR, or bundle it with Grin, which could be non-trivial, and could conflict with locally installed/running versions. # Unresolved questions -* How should we encode addresses? base32, base58, emoji, etc. * How often should addresses change? Should users manually request a new address, or should they auto expire? Should we support multiple? # Future possibilities