From mats.jerratsch at blockchain.com  Tue Dec  8 17:13:22 2015
From: mats.jerratsch at blockchain.com (Mats Jerratsch)
Date: Tue, 8 Dec 2015 17:13:22 +0000
Subject: [Lightning-dev] Onion-Routing for Messages
Message-ID: <56670FB2.7030108@blockchain.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I've been thinking a lot about the Onion Routing we designed a couple
of weeks ago and how we would use it in practice.

So I am in full privacy mode currently and I would prefer to design a
system in which sender and receiver of a payment by default do not
learn any additional information about each other. This means that
payments will - by default - get routed over a rendezvous point(RP)
and encrypted using a onion scheme.

So if A wants to make a payment to E, E will choose a RP C and create
an onion object which will allow C to route the payment further
towards E. A will not know which node is receiving the payment, A only
knows that it should route the payments towards C. So A uses the
object E sent him and wraps the onion layers for the routing towards C
around it. When C receives it, it does not know that A sent it, nor
that it should be relayed to E finally. It will just follow the
instructions E put in the onion object.

In practice E can use a (reasonably sized) QR code to transmit this
blob of data to A.

However, we have to decide whether we want this whole onion-routing to
be one-time and one-directional or not.

The design where we stopped few weeks ago did fill up the onion
objects with zeros, so unless the nodes store some data to relate to
that message later, it is not possible for the receiver to send a
message back to the sender. (or to have any additional communications
at all for that matter)

This means we would need to transmit the payment hash together with
the blob in the QR code. Furthermore, if the payment goes missing, we
need some additional communications channel to address routing of the
refund payment. (NFC would qualify for that if we are using a mobile
wallet)
It also means that payment requests are one-time only, as they include
the payment hash. (even though we could try to do some fancy things if
we settle for EC keys for payments)


On the other hand, it would be possible to have a message system
integrated. When parsing the onion object, each node could encrypt and
append the pubkey of the node it received the object from together
with the ephemeral key used initially. When the receiver wants to send
a message back, he encrypts it using some designated ephemeral key
included by the sender and uses the onion object to send it back. The
nodes on the route can unwrap the onion object again to route it back
to the original sender.

This means that a payment request is just a way of contacting the
receiver to obtain information about making a payment. It can be
stored and reused whenever you want to make a payment. You can also
send the necessary signatures for the pay-to-contract scheme as
include other data necessary if we want to implement something like
Proof-of-Payment. In general, it would allow for very general purposes.

Which - on the other hand - is also problematic. It is difficult to
provide a reasonable DoS protection against nodes just spamming the
network with unnessesary messages. We could assign super tiny payments
to the process of sending a message to counter spam, but it might be
difficult to implement.

Additionally it serves a security risk, as someone obtaining the onion
object can 'hunt down' the sender by targeting the nodes consisting
the route one by one. Currently this is only possible for tracking
down the receiver. For one to succeed in such a task, it is necessary
to extract the private key used for encryption for ALL nodes in the rout
e.

- -- 
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWZw+yAAoJEAYZmwZ/PsbK7soQAILSfSsENE9a87YU7xBj5Cws
B35rPYBVHcUCLWRIEOsEd3FCRmMDNQUGkzMFMaMXwWEBkVV5+csDhSCQxP8WdV3V
b8Y/ZzkpiMj7FUdFp64dNtUken24ixgbPK1tCGyhTiDb47uUWr1GeeF+wL51oSXp
ua2XM+y07RO9ghO7Sl25vAjQqeuN4tmoEU6u0AWGw9L0vVIFz/J6IXCjUG4w/ruo
7ljMUaSwir65euEmr1OEMGyB1doB6YBB5TmcRCP2sDENSdGizc9wQ0xeGeb9h8Kd
ZrggdX/NXpU4PS6Mn+SGNdJoVjv/NincQ5ZBBm6qtWC0f4Nq2nXgb/ISuEk/01Lp
3MNZu3r1pM5GJ7VH+zbmJxxv4sfI7GCY+D9is8hAN5IXCSaeTwkSJY3qzevWrP/h
5DSStjPU8K6h1JAiD+TDX1XtVNSmx7IKrRH1rEcQC6SmePYe871fQNFU1qdUro/P
JMIza4uRrHcyI/RjLGLQoy+EHCO+LbkXzmW/7k/trAZZWZ6f6F/wtCpDAKHPsl9q
udzjWIqv+3FHrjpgGW6WwrYzvkxDQ4rJPrSm+C/96Us4ePLn1syq+Z9m40xF/jZU
XXmGuu8Cx9mYk8/Dthv7Zs0muK2QC0UoAYpMuWQnAYWikeTWHYgaGD33hAz43Xwt
96Mt8FoNhSGLKoL+5YuI
=qWKx
-----END PGP SIGNATURE-----