Requirements for Quick Connect 2.0?

[ChristopherA]

A number of projects are supporting Quick Connect 1.0, which allows wallets to connect to bitcoin full-nodes via a TorGap.

Server-side full-node manufacturers or providers supporting Quick Connect 1.0 include BTCPayServer, Nodl, MyNode, RaspiBlitz, GordianServer, and of course Bitcoin Standup.

Wallet applications supporting Quick Connect 1.0 include Gordian and Fully Noded.

(if you support Quick Connect 1.0 and are not on the list above, either reply here or offer a PR to the Quick Connect 1.0 page so we can add you.)

We'd like to evolve this specification for 2.0 to address at least two new requirements:

• There is a need to be able to offer multiple services from a single server, for instance Bitcoin mainnet, testnet, Lightning, Spotbit, etc. Thus primary goal for a Quick Connect 2.0 specification is a single QR from a server that can offfer a client a list of all services available to it.
• A secondary requirement is that some servers may be able to use Web camera APIs to scan QRs from clients, and we'd like a QR with Tor v3 client information in it that can be passed back to the server.

We'd love to have more discussion with other wallet developers about any additional requirements for this initial connection between a full node and a remote device via tor. This could include a possible TOFU two-round auth so that the node can know that the specific remote device is the same one that requested it originally. If these QRs might get large, we might also want to offer this as an animated QR using self-describing UR format rather than javascript.

/cc current supporters: @Fonta1n3 @NicolasDorier @nodl_it @raspiblitz @mynodebtc @wolfmcnally @gorazdko

/cc potential supporters: @getumbrel @BTCxZelko @Kexkey @samouraiwallet @greenaddress @jonasnick @wasabiwallet @Kixunil @kallewoof @bajohns @sponnet @HtcExodus @Start9Labs @Stadicus @k3tan172 @seth586 @burcakbaskan @kdmukai @bavarianledger

[Kixunil]

YEEEEES!!!! This is exactly what I wanted to bring up a long time ago! You can count on me to write the server impl, desktop client and having the time to do it.

My own requirements that should be easily met:

• The possible services MUST NOT be hard-coded in any way. If someone creates a new app, he MUST NOT be required to register it anywhere for it to work and definitely not change any code of anything else. Registering a domain to have a unique name of the service could be optional but having a random UUID is also a possibility. Not sure what's best here.
• There should be a way to connect things without QR code, just the link or having a configuration file placed at specified location(s)
• Do not tie it to Tor which can be slow but have the ability for users with a public IP address or other means of tunneling (VPN) to use a faster option
• Some kind of permission system - this can be done entirely server-side where the server just hides forbidden services from the client, so no need to put it in spec but if there's an opportunity to improve the UX by transporting the data, we should take it

My top priority is awesome UX and I have no problem to make the system more complex to achieve it.

I think this whole topic can be broken down to several components:

• client - server protocol
• Things specific to Android environment
• Things specific to iOS environment
• Things specific to desktop environment

When thinking about this before I came to conclusion that it would be good to have a bridging app which can remember the credentials and pass them to other applications without scanning the QR code again. Maybe it'd be best to focus on specifying this side first and come up with the protocol later. This version has also one significant advantage: the apps don't have to implement every single transport available (Tor, SSH, TLS, VPN...) only the common app needs to. Not sure if this is possible on iOS devices though.

Gotchas to keep in mind:

• LND changes the certificate occasionally which breaks all connected apps. The protocol should be flexible enough to fix this. (LND could also be changed but having the option to fix it for any service with similar issue seems better)
• I guess some users will want to share their node safely. E.g. allow read-only access to bitcoind (definitely don't allow calls like invalidateblock or sendtoaddress), the protocol should not stand in their way of doing so (there's a good chance they will do it unsafely otherwise)
• Without some key rotation, the QR code is kinda toxic waste. I think it'd be best to make it one-time-use and let the apps exchange new tokens in the background.
• "If these QRs might get large" - we should make everything we can to avoid this in the first place

A URI scheme I was thinking about:

NODECONN:<VERSION><SECRET_TOKEN><TRANSPORT_ID><TRANSPORT_ADDRESS>

VERSION is semver, set to 0.0 with optimal encoding for QR codes. SECRET_TOKEN is exactly 128 bits (16 bytes) in whichever encoding is the most optimal for QR codes. TRANSPORT_ID is T for Tor V3, other protocols to be specified, but roughly: S for SSH, I for bare IP - lightweight encryption can be done using ECDH (secp256k1) authenticated with HMAC(SECRET_TOKEN, ECDH_PARAMS)

TRANSPORT_ADDRESS is transport-specific, onion for tor (without trailing .onion and possibly reencoded if there's a more optimal encoding for QR codes), IP address for IP reencoded as upper case hex (8 hex digits), others not yet specified.

Another approach I was thinking about is making SECRET_TOKEN part of TRANSPORT_ADDRESS and leave encryption to transport. E.g. one could put SSH key into TRANSPORT_ADDRESS and assume SSH is sufficient encryption.

After connecting to the server, the client and server should exchange long-lasting keys. Then the client can obtain the list of available services and can request connection information specific to each service.