-
Notifications
You must be signed in to change notification settings - Fork 0
Addresses
MimbleWimble transactions are constructed interactively.
Thus, a payee must supply enough information for the payer's wallet to connect to the payee's.
These pieces of information, whatever form they take in Grin, although different in detail from traditional cryptocurrency addresses are similar enough in function that they could be referred to as "Grin addresses".
Currently, a payee supplies their IP address and port, and the payer's wallet connects to that address and initiates the transaction. This is vulnerable to man-in-the-middle attacks, so a another scheme will be needed for long-term use.
I have not included port numbers, which may be necessary if the payee is using a port other than the default.
PUBKEY_HASH@IP_ADDRESS
Bob gives Alice his wallet's pubkey hash and IP address. Alice connects to his wallet using the IP address, and authenticates and encrypts the connection using the pubkey hash.
- Simple
- No additional configuration
- IP addresses may be dynamic, so payee strings may not be valid indefinitely
PUBKEY_HASH@DOMAIN
Bob gives Alice his wallet's pubkey hash and domain name. Alice queries the DNS for Bob's wallet's IP address, initiates the connection, and authenticates the connection using the pubkey hash.
- Simple
- Payment recipients must register a domain name and ensure the relevant entry is kept up to date
- Domain name registration often requires users to supply personally identifiable information
DOMAIN
Bob gives Alice a domain name only. Alice queries the DNS for Bob's IP address, initiates the connection, and authenticates the connection using TLS.
- Simple
- Payment strings are just domains, so are short and readable
- Certificate authorities are central points of failure that can be corrupt or compromised
- Payment recipients must register a domain name and ensure the relevant DNS entry is kept up to date
- Domain name registration often requires users to supply personally identifiable information
- Obtaining an certificate from a certificate authority can involve additional costs and more involved configuration
4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad
Bob gives Alice a Tor hidden service address. Alice looks up the hidden service's onion service descriptor in the onion service directory, a distributed hash table. The descriptor enables Alice to establish a circuit to Bob's node. The connection is authenticated as a Tor hidden service address is a pubkey hash.
- Bob and Alice can transact without knowing each other's network location, which increases privacy as well as reduces exploitable attack surface
- Handles NAT traversal, so no firewall configuration would be necessary
- A new address can be generated for every incoming payment
- Less "fork surface". Entire cryptocurrencies exist that are just "cryptocurrency X + Tor". Integrating Tor would thus seem to be a nice marketing point, and would prevent such a fork from diluting mindshare
- Tor hidden service addresses are a base 32 encoded SHA-1 hash, truncated to 80 bits. SHA-1 is vulnerable to collisions, and even so, 80 bits is not a lot. Fortunately, these issues are fixed in the next generation of Onion services.
- Requires a local Tor node
- Tor is written in C, and depends on OpenSSL, zlib, and libevent. It uses the standard configure / make / make install. It can be built statically. Static prebuilts are available for Windows, and it is available in every distro's package collection.
- Tor has limited support for using it as a library. Using it as a library is pretty immature, and we would still want to fork into a separate process, since it might mess up logging / exit the process on failure. The Tor project is happy to accept patches that improve this situation however.
- Tor doesn't require any special privileges. Grin could create a tempdir with the configuration files that Tor requires and then launch it, using command line options to point it to its configuration.
- The payee would run a Tor hidden service. This is accomplished by launching a Tor instance, an configuring it to forward incoming requests to a local port.
- The payer would make requests to the payee's hidden service. This is accomplished by launching a Tor instance and making requests to a local SOCKS proxy it serves.
- As far as I can tell, we could configure the local Tor instance entirely using configuration files. The wallet would just launch an instance, watch the PID, and kill / restart it as necessary.
- Since we would be consuming resources in the Tor network, we can be good citizens by given resources back by running Tor nodes ourselves. If we do this, to fully offset our usage of the network, we should contribute 6x the bandwidth we consume, since our bandwidth will be going over a 6 hop circuit.
rjxwbsw4zjhv4zsplma6jmf5nr24e4ymvvbycd3swgiinbvg7oga
I2P is similar to Tor. Bob would give Alice a I2P eepsite address, after which we proceed similarly to Tor. Advantages and disadvantages are also similar.
fc4d6beb5513ebb8520948969ecbeb9585083307c1bc0f87f7665515045cf3bf@89e92ceee5
ZeroTier is a zero-configuration virtual networking layer. Data streams are encrypted, but network locations are not obfuscated. ZeroTier addresses are 40 bits, and look something like 89e92ceee5
. Since 40 bits can be brute forced by a well funded attacker, it seems prudent to avoid relying on it as the sole means to authenticate and encrypt a connection.
Bob gives alice pubkey hash, plus a ZeroTier address. Alice's node connects to the ZeroTier "planet", which is a distributed group of servers run by ZeroTier. Alice will then communicate with Bob via proxy, through the planet, or via direct connection if one can be negotiated.
The connection can then be authenticated and encrypted using the pubkey hash.
- Handles NAT traversal, so no firewall configuration is necessary
- A new address can be generated for every incoming payment
- Free version limited to 100 devices. The next tier up, which allows unlimited devices, is $29.00 per month.
- Relies on ZeroTier's planet infrastructure. We could run our own planet, to reduce our dependency on ZeroTier, but that would still be infrastructure we would need to run.
grin1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
Grin could create a Grin-specific distributed hash table that all nodes would participate in.
Bob gives Alice a pubkey hash. Alice looks up Bob's IP address in the DHT and initiates the connection, authenticating it with the supplied pubkey hash.
- Avoids external dependencies
- Nontrivial to implement