P2P transaction building

[hashmap]

It would be beneficial for user experience to implement p2p transaction buiding, secure and nat/firewall friendly. The current methods have the following drawbacks:

• HTTP requires the server port to be reachable, which implies a public IP address and firewall configuration. It limits some home networks and most of mobile networks. It is not secure by default. TLS support has been implemented but it requires a public static main, sorry, IP address (or a service like DynDNS) and a domain name.
• File exchange requires a good understanding of tx building protocol, careful use of an external secure channel and in overall provide a bad UX.

Proposed solution is to use our existing p2p network as default secure channel and automate protocol.

• Each node advertises a public key as part of peer info
• Node ID is created from the public key
• Alice communicate her pk or node id to Bob (eg send in an invoice). In the future a presence and signaling service could be implemented on top of p2p network to allow have a contact list and see online presence as we have in messengers and to send an invoice/payment request
• Bob creates a tx slate, encrypt with Alice's pk
• If Bob has Alice peer info in db he tries to open a direct connection
• Otherwise (no info or Alice is behind NAT) Bob sends a route discovery request. As result he gets IP:PORT. It may be the address of Alice (if she is reachable directly, see Distinguish between two types of p2p nodes #1797 ) or and address a reachable node connected to Alice (Faythe). In the simplest case it could be implemented via flooding the network. Another option is to use XOR distance from Kademlia protocol https://en.wikipedia.org/wiki/Kademlia#Routing_tables Kad protocol is designed to return a subset of nodes, we need a particular node, so it's a simplified version of Kad peer discovery.
• Bob proceeds with slate exchange, sending a special message with Alice node id in the header. Faythe acts as a proxy.
• After receiving the message Alice can try to establish a direct connection to Bob or continue sending via Faythe.

If Bob sends a spam message Alice bans him.
Network nodes could ban Bob if he sends a message to unknown address. In flood model nodes could keep "seen" counter for recent messages and ban if it was seen more than N times. In Kad-like system an intermediate node will discover that there is no Alice because he is the closest node to this address and he is not Alice, so he bans Bob and ask his peers do the same.

[antiochp]

@hashmap Want to see a protocol (and implementation) that will blow your mind? (It just blew mine).

http://www.lothar.com/~warner/MagicWormhole-PyCon2016.pdf

https://github.com/warner/magic-wormhole

I was reading about PAKE (https://en.wikipedia.org/wiki/Password-authenticated_key_agreement) earlier and came across a mention of "magic wormholes" as seemingly literal magic.

Edit: https://github.com/warner/magic-wormhole.rs (WIP rust impl from same author).

[pcdinh]

Great summary. I asked a related question at Reddit Beam and Grin last month https://www.reddit.com/r/beamprivacy/comments/9fh37f/is_there_any_idea_to_enable_noninteractive/ Beam seems to have a different way to achieve it but not implemented it yet

[sesam]

Great catch! We probably must implement this. Even for the name confusions alone :). And occupy the protocol name "mw" as in mw://[magic wormhole keywords] Nicely short for long-distance readable qr codes, and fairly easy to display and retype too. Any already used wormhole leaves behind a "seed" from which another identical wormhole can be grown (a seed for another PAKE round) which means grin's interactive TX construction can be done offline, with periodical messages being exchanged, possibly over an air gap. The mw:// protocol is built to support different applications (the application identifier string) and a mw:// handler would decide which app should be activated depending on the app string. Would we need create an "ASCII armored" message for starting a grin tx "handshake"? UPDATE: probably could just use a app id string for each usecase.

[lehnberg]

Putting the thoughts I raised on Gitter/dev re this here in a slightly condensed/reworded fashion:

Magic Wormhole does look quite elegant, yet I wonder how fit it is for this purpose. A user could basically send a tx to another by having both sending and receiving users type in sth like 7-guitarist-revenge (or some other simple combo of mnemonic words).

As I understand it, this would still require the sender and receiver to exchange the (one-off) mnemonic sequence securely in some way. How would this practically be achieved? As per the possible attacks in the documentation (https://magic-wormhole.readthedocs.io/en/latest/attacks.html), it seems as if this mnemonic is intercepted, it opens up for MITM attacks.

If you have such a secure comms channel open between Sender and Receiver to exchange magic words mnemonic on, why not use this channel to exchange slates instead as part of async-transaction building?

[sesam]

magic-wormhole cons:

• more complex than copy&paste through existing channels
• not yet implemented in rust? Probably a large task.

pros:

• userfriendly with a short code
• usable independently of communication channel (voice, smoke signals, etc)
• easier to verify the other side through a one-shot channel

UPDATE: and it can be static and like a vanity pay-nym given some adjustments (below)

[sesam]

tl;dr: I think wormholes are a better fit than a p2p overlay.

In depth:

Possible attacks on grin wallet send + wormholes:

• DoS? Mitigations: add more wormhole channels (more underlying transports, more codes, more rendevous alternative transports/servers like Aloha/mDSN and Chirp/audio and even some light or visual spectrum alternatives, stegano., etc)
• metadata profiling: those who use wormholes through watchable rendevous servers will stand out to any meta data profiler, but only as long as few people use them. Mitigations: get more users, hide wormhole steps, slow down the wormhole steps, make wormholes more popular also for other use cases than crypto payments
• MITM: Mallory would have to
  1. complete the transaction preparation with Alice, Mitigation: out-of-band checking along the way
  2. create a new channel with the same code -- OR just break the communication link between Alice and Bob and tell Bob another code altogether (grin can list some good/bad out of band options, Signal etc). Mitigation slow down the wormhole, so Alice and Bob can out-of-band comment on the progress.
  3. not be detected by Alice before she completes and publishes her payment to whoever succeeds to listen (typically the other part, who would be responsible for publishing the transaction in order to get the funds). Mitigation: If Alice / Bob notices comm. channels failing or notifications about channel key changes, they should be recommended (maybe by the wallet software) to rather retry their transaction later, maybe on another internet provider, to not risk potentially malicious disturbances.
     For larger transactions grin could suggest spreading the tx preparation process over multiple wormholes.
• active adversary who can divert packets or replace in transit: Out of scope? :) Interleaving comms over many wormholes? Maybe add some automated third party to help watch over the process,
  to make it necessary to attack more channels without Alice noticing that anything is wrong.

The wormhole code (number-word-word) could perhaps be revealed step by step to force the sender and receiver to work in concert and use some out-of-band communication channel, potentially lowering anonymity (metadata/timing) but making MITM attacks much harder. The magic-wormhole tool is maybe most commonly used to send hard to type / hard to verify key files and secrets, where discovery of the first and only data payload can be catastrophic. But grin risks nothing until the transaction is fully built and sent to the recipient (who would typically be responsible for getting it published and mined).

I've used magic-wormhole before, but mostly one-way, sending public keys, but the existing implementations are built to support multiple use cases. Even more than Chirp supports.

For semi-permanent "node addresses" or pay-nyms, donation addresses, etc previous suggestions include publishing ip:port anywhere safe, maybe in signed DNS TXT or SRV records, to use grinbox, or to use some coin that supports pay-to-address.

Regarding the original suggestion that hashmap wrote about --

Proposed solution is to use our existing p2p network as default secure channel
-- I think grin p2p nodes could be a welcome complement to the existing magic-wormhole reflection solution, maybe even if it would become a paid reflection service.

I suspect that a recipient-initiated wormhole is a better fit than p2p flooding/gossiping that reuses node identifiers. I worry that this IP:port:timestamp will be tracked and used, for instance for market manipulations (short, attack nodes, profit) or otherwise. If it needs to be p2p with permanent identifiers, then maybe just use i2p.

[sesam]

If you have such a secure comms channel [...] to exchange magic words mnemonic on, why not use this channel to exchange slates instead as part of async-transaction building?

magic-wormhole is

• not a shared-secret scheme (like ad-hoc wifi networks, or OTP chat) where you agree on a key, and anyone having the key also has full access to read/write/modify communication freely
• not a classical shared-nothing / zero-knowledge setup where anyone in between can transparently MITM by rewriting network traffic
• not like e2e secure chats like Signal, where the channel key is rotated over a longer period of time, and you might get a "surprise key change" warning on which people typically just click OK and forget about it or just ignore security.
• not well-tested yet? The python implementation is ~2 years old, but maybe not heavily used. Maybe compare SSH which took a long time, but is now used by everyone and for almost any possible use-case.

The "crypto" used or magic-workhole seem well-understood and trusted: SPAKE2, Salsa20/Poly1305

The magic:

• An active MitM gets one guess per wormhole.
• Failed guess=no information leak.
• Failed guesses are detectable by users.
  wormholes use 256 words, 256^2 = 16 bits
  655 tries (and equally many detected workhole failures) gives 1% chance of stealing a wormhole
  From: www.lothar.com/~warner/MagicWormhole-PyCon2016.pdf

After a PAKE it opens an encrypted pipe using NaCl (Salsa20/Poly1305), keys = HKDF(masterkey, purpose). Some hashing with SHA256 (probably for a fast check against data corruption or chunking or something)

Sorry if I'm too "hot" for the wormhole idea. I do think we should take time to understand this option properly, also if the only result is that we understand where PAKE is and isn't useful.

[ignopeverell]

I might be repeating myself but what's wrong with i2p? You do get a stable publicly addressable identifier by default, mitm resistant, onion-style relay so good privacy, it's lighter than Tor and somewhat embeddable (i2pd), we can find other uses for it (like the regular p2p), and it serves a good cause to add more i2p nodes.

What are the advantages of other solutions in comparison? The only thing I can think of is they may be lighter weight.

[hashmap]

I started thinking it's a right way, I got an impression that integration with i2p is not an easy task (see kovri), but it seems I was wrong.

[0xmichalis]

Naive question: is it possible to use Kovri? Pros/cons?

[ignopeverell]

Kovri is a fork of i2pd so at a high level no difference. But it's a bit drama-land, see here for background (including the last link):

https://monero.stackexchange.com/questions/2324/what-is-the-difference-between-i2pd-and-kovri

Since 2016 it looks like the i2pd project has cleaned up and matured, while Kovri is still in pre-alpha. There are numerous i2pd instances which have been running for a while and it's stable.

[0xmichalis]

I like the idea of enabling grin (node+wallet) via i2p and i2p having its own community already is a plus.

[lehnberg]

I have no i2p/i2pd experience, so cannot comment about its suitability for us. On paper, if it works as it should, then it seems like it could be a good solution, with i2p looking bloated/overkill compared to i2pd/kovri, which would probably be more suitable to our fairly focused use-case.

Reading that stackexchange link (and the last link) though doesn't exactly fill me up with confidence of either i2pd or kovri projects. And they are C++ which (to me) seems like something we should try to avoid if we could.

There are some existing Rust i2p projects, most notably https://github.com/str4d/ire, but they don't seem very mature.

From what I could dig up quickly, current rust p2p projects that could be suitable candidates:

• https://github.com/libp2p/rust-libp2p, by Parity/Polkadot, which I think @hashmap had already looked into using, but did not think was desired? Don't remember the justification, but I trust his judgment.
• https://github.com/maidsafe/crust, by Maidsafe. Don't know much about it or whether it's sufficient. Has anybody else looked at it and can comment? More info here and here .

Other than that, other routes I can think of would be:

• Build something on top of what we have (as per Hashmap above)
• Create and maintain a rust implementation of i2p/i2pd. I have no idea about the effort required, but I could imagine it would risk becoming a distraction.

Left field: https://github.com/majestrate/XD is an i2p Bittorrent client written in Go. Possibly there's something we could use from there?

---

edit: added more URLs related to Crust.

[0xb100d]

@sesam there is a rust port started but very incomplete https://github.com/warner/magic-wormhole.rs

I am with you, synchronicities abound and this is usually auspicious (this is the extent of my contribution to discussion unfortunately!) the MW:// naming coinincidence is too good. The mitm risk appears small from his talk, and ddosing/mitm is mitigated by longer word strings if I understand it. it also seems very lightweight, and the UX experience of magic words is the most complementary thing I've ever seen. I already got some magicwormhole stickers from him, and the hat-logo-sticker fits perfectly on the grin stickers-smileys. need I go on?

I've heard that kovri is quite heavy to include in monero wallets, and it seems like many/most people already are going to be using tor and have it installed to begin with, so could be redundant to some extent?

@ignopeverell has good point that i2p is more mature/wider interest, so grin contributing nodes is a benefit outside of the project.

[dinnerisserved]

I think that using using something like X3DH with Double Ratchet and utilize what is being used by many as communication framework would work perfect for the requirements in sending messages between peers in Grin.

A different alternative to the Signal implemented X3DH would be https://git.matrix.org/git/olm/about/docs/megolm.rst

Alternatively OMEMO seems to be quite interesting: https://conversations.im/omemo/ as it allows for peers to use multiple devices.

I think it however would be a shame to implement a specific way for communicating transaction building within Grin itself. Allowing third party application to use whatever they want, encrypted, unencrypted, kademlia or server based or pastebin opens up for interesting future third party integrations.

Exposing a set of good solid API's via the Grin build would be a much cleaner approach to letting third party integrations happen.

[lehnberg]

@dinnerisserved in general, I agree what you're saying. Principally, and in an ideal world, I think it makes sense to keep Grin itself minimal and let others build services on top of it. And yes, X3DH / Signal and Matrix have been considered in the past as well. First time I hear about OMEMO though, and seems indeed interesting.

I think it however would be a shame to implement a specific way for communicating transaction building within Grin itself.

The reasons for doing so I think would be for usability and getting the entire userbase on one single comms protocol. If one wallet goes and implements X3DH and another uses OMEMO, then different wallet users may not be able to transact as easily with each other compared with if there was a single foundation that every grin wallet would be reachable on. It's nice for a new user to have a wallet that just works and supports sending and receiving to other users straight out of the box, without having to worry about stuff like leaking IP addresses, configuring SSL certificates, or what wallet the recipient is using.

Allowing third party application to use whatever they want, encrypted, unencrypted, kademlia or server based or pastebin opens up for interesting future third party integrations.

One thing doesn't exclude the other though, right? There could be a universal P2P protocol implemented, whilst pastebin transaction building could still be supported via third party integrations if there's a need for it.

Exposing a set of good solid API's via the Grin build would be a much cleaner approach to letting third party integrations happen.

Whilst it's not an API, this is already supported to some extent today. Grin wallet supports file based transactions, which would enable someone to build the third party integrations you mention. Do you see ways we could improve on the current implementation and make it better? https://github.com/mimblewimble/grin/blob/master/doc/wallet/usage.md#send

[lehnberg]

related: #1437

[gpestana]

@lehnberg

https://github.com/libp2p/rust-libp2p, by Parity/Polkadot, which I think @hashmap had already looked into using, but did not think was desired? Don't remember the justification, but I trust his judgment.

It seems to me that rust-libp2p net stack is getting mature enough and being actively developed. IMO, a good option which is and will be maintained in the future and definitely would provide us a lot of goodies out of the box (NAT traversal, peer discovery, secure channels, etc..). It also seems that many projects are adopting libp2p as network stack, which is a good sign and ensures project maintenance in the long run.

I could look more in detail whether the current rust-lip2p implementation would be a good fit now and if not yet, then when.

[lehnberg]

I could look more in detail whether the current rust-lip2p implementation would be a good fit now and if not yet, then when.

@gpestana go for it, absolutely!

[hashmap]

@gpestana what I found - I might be wrong - from my experiments and conversations with libp2p team and rust-libp2p author:

• NAT traversal in Rust version is supported rudimentary and not in the top priorities
• libsecio (libp2p transport encryption) will be replaced by TLS 1.3, but no target date yet
• Rust version is built on top of Tokio, we ditched an existing Tokio-based impl about a year ago, can't comment on reasons, afaik complexity was very high

[gpestana]

@hashmap that sounds about correct.

[sesam]

we discover that a censor can block more than 95% of peer IP addresses known by a stable I2P client by operating only 10 routers in the network

from An Empirical Study of the I2P Anonymity Network and its Censorship Resistance (Sep 2018)
by Nguyen Phong Hoang, Panagiotis Kintis, Manos Antonakakis, Michalis Polychronakis

[lehnberg]

web3 foundation recently announced an effort that seems highly relevant to this: https://github.com/w3f/messaging

[yeastplume]

Out of date and addressed by TOR