Compare transaction-building alternatives

[lehnberg]

Following discussions in the wallet-dev team on keybase this issue tries to compare the options for transaction building methods considered for use in Grin. Method and criteria definitions are below the table.

Most of these scorings are subjective and in relation to the other methods. Feedback is desired. Write below with request for modifications of scores, or for additions or removals of methods and criteria.

---

Scoring legend

🟩	Yes, excellently
🟡	Yes, a little bit
❌	No, not at all
🔷	It depends. (Extraneous)

Note: While everything can be made to work, the intention is to provide the most generally accurate verdict, as-is, without hacks.

---

Comparison table

	https	Tor	Text / QR	P2P network	Federated relays
Privacy & Security
E2EE	🟩	🟩	🔷	🟩	🟩
Clearnet	🟩	❌	🟩	🟩	🟩
Tor	❌	🟩	🟩	❌	🔷
IP protection	❌	🟩	🟩	🟡	🔷
Meta-data protection	🟩	🟩	🟩	🟡	🔷
Usability
Asynch	❌	❌	🟩	🟡	🟡
Payment proofs	🟡	🟩	❌	🟩	🟩
Mobile friendly	🟡	🟡	🟩	🟡	🟩
User friendly	❌	🟩	🟡	🟩	🟩
Service friendly	🟩	❌	🟩	🟩	🟡
Complex use cases	🟩	🟩	❌	🟩	🟩
Fire-forget-friendly	🟩	🟩	❌	🟡	🟩
No address exchange	❌	❌	🟩	❌	❌
Network considerations
Lightweight	🟩	🟡	🟩	❌	🟩
No SPOF	🟩	❌	🟩	🟩	🟡
Attack-resistance	🟩	🟡	🟩	❌	❌
Censorship-resistance	🟩	❌	🟩	🟡	❌
No funding risk	🟩	🟡	🟩	🟡	❌
Scales well	🟩	🟩	🟩	❌	🟡
Resource agnostic	🟩	🟩	🟩	🟡	🟡

---

Methods

Included

Method	Description
https	Vanilla https communication, as per current wallet implementation.
Tor	Using Tor hidden services, as per current wallet implementation.
Text / QR	Slates are compacted, armored, and serialised as required, to produce one or more strings of text and/or QR codes.
P2P network	SBBS-style or "slatepool", possibly using stealth addresses or PIR techniques, plugged directly into Grin's p2p network.
Federated relays	Grinbox-style, possibly using stealth addresses, Tor hidden services, PIR techniques, runs as federated services that are not part of Grin's P2P network.

Not included

Method	Motivation
file	< text blobs in every aspect
http	is just bad and not an option
hybrid transactions	it's a combo of methods considered, no need for its own category
centralised service	method should not depend on a single entity

Evaluation Criteria

Criteria	Description
Privacy & Security
E2EE	Is communication end-to-end encrypted?
Clearnet	Does it work over regular Internet?
Tor	Does it work over Tor or other overlay networks?
IP protection	Does it obfuscate transacting parties IPs?
Meta-data protection	Does it avoid giving observers metadata to deanonymize transactions?
Usability
Asynch	Does it allow one party to be offline while the other sends?
Payment proofs	Does it enable proving that a particular sender and receiver transacted?
Mobile friendly	Does it work well on Android and iOS?
User friendly	Is it easy for users to use, are the conventions familiar?
Service friendly	Is it easy for Exchanges, Mining pools, and other businesses to support?
Complex use cases	Does it offer good support for advance use, such as multi-party transactions, programmable routing, atomic swaps protocols?
Fire-forget-friendly	Does it support a simple "send to this address" permanent message for receiving funds?
No address exchange	Does it avoid the extra communication trip of discovering a particular destination address?
Network considerations
Lightweight	Does it avoid introducing complexity to Grin?
No SPOF	Does it avoid a critical dependency that becomes a single point of failure?
Attack-resistance	Does it avoid spam / DoS attack vectors ?
Censorship-resistance	Is it straight forward to censor the traffic?
No funding risk	Does it avoid creating a "tragedy of the commons" scenario where added infrastructure is required to run at a loss in order to support the method
Scales well	Does it scale well as transactions and users grow?
Resource agnostic	Does it work on most hardware resource or network connection speeds?

---

Changelog

• Apr 20: Initial version
• Apr 20: Adding payment proofs criteria & changing User friendly scoring as per @DavidBurkett feedback.
• Apr 22: Changing mobile friendly scoring for Tor as per @johndavies24 feedback
• Apr 24: Changing mobile friendly scoring for https as per @johndavies24 feedback

[johndavies24]

Tor should be made either entirely mobile friendly or at least "a little friendly" since the reference wallet for verge exists with tor on both iOS and android and the blockstream green wallet for bitcoin has tor on both iOS and android. There are likely more examples, but I am happy that blockstream released one so I didnt have to rely on verge as my example, lol.

[lehnberg]

The definition I put in was:

Mobile friendly | Does it work well on Android and iOS?

I don't know whether Verge or Green work well using Tor. I've got Green wallet, but have not been using it enough to form an opinion on it. It's all very subjective in any case, and since it's open source code it's clear that a developer who's motivated can make Tor work on mobile without third party apps. So I've changed the score to 🟡 there as you suggest. I'd say it's a weak yellow, but probably more fair than the previous ❌ score.

Thanks for the feedback, please keep it coming. ✊

[lehnberg]

Actually... now that I think of it two minutes more... It's one thing to relay inbound/outbound network communication over Tor, it's a different thing altogether to run a Tor hidden service, which is required in order to receive a Grin slate. Is it possible to run a Tor hidden service on mobile? @DavidBurkett do you happen to know by any chance?

[johndavies24]

HTTPS could be made to "a little" for mobile as well. Beam wallet does HTTPS on both iOS and android. For both scenarios (HTTPS and tor), iOS strictly does not allow the services to run in the background so it is only active when the app is open in the forefront. Android allows both to run in the background. Sending will always have the app open, so it doesnt matter. But receiving in the background will only work on android.

[DavidBurkett]

Actually... now that I think of it two minutes more... It's one thing to relay inbound/outbound network communication over Tor, it's a different thing altogether to run a Tor hidden service, which is required in order to receive a Grin slate. Is it possible to run a Tor hidden service on mobile? @DavidBurkett do you happen to know by any chance?

On Android, it's absolutely possible. Orbot supports it. For iOS, I'm not sure. Apple is pure evil, so they probably make it as difficult as possible. As John pointed out, they have a lot of limitations around allowing connections, so any "online" solution is likely to be impractical.

[johndavies24]

Yeah, for example, beam wallet on android will periodically check for transactions and retrieve them in the background but on iOS the user must open the wallet to have any chance of receiving their tx. I know you could force always on in the background with android, but it would likely damage battery life and whatnot.

[lehnberg]

I've updated https to 🟡 on being "mobile friendly". I think both Tor and https are borderline here, personally I wouldn't call any of them "mobile friendly" (at least not for wallet developers), but it's subjective. Happy to lean in this direction, after all, that's what the 🟡 rating is there for.

Pls keep feedback coming!