From mats.jerratsch at blockchain.com Wed Dec 9 09:45:20 2015 From: mats.jerratsch at blockchain.com (Mats Jerratsch) Date: Wed, 9 Dec 2015 09:45:20 +0000 Subject: [Lightning-dev] Onion-Routing for Messages In-Reply-To: References: <56670FB2.7030108@blockchain.com> Message-ID: <5667F830.7050904@blockchain.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > I have sort of lost track of preferences regarding what is to be > sent through onion routing versus what's not... Agree, it hasn't been on list for quite some time, the last time we discussed it, we only included the route in there. http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/00 0247.html Back then only the pubkey of the next hop has been part of the onion object, with no additional message to the final receiver. For having the added privacy of changing R value we would probably add a random number in there as well. > Originally I had assumed that some out-of-band messaging would be > taking place (like an equivalent to a BIP70-style payment > protocol). Rather than a single QR code, I was expecting an > interactive wallet-to-wallet protocol while both sides are busy > communicating with the onion routing network for the actual payment > route negotiation stuff. When they ultimately find that no > sufficiently cheap route exists, then the wallets would opt to > create a new payment channel in some circumstances. Interesting. I think the important term here is 'out-of-band', as I would implement above using the actual lightning network. But I also fail to see how to implement a secure and private communications. I guess one way would be to have wallets open up a hidden service on TOR and take payment requests on a service listening there. But it would not exactly reduce complexity nor would provide sufficient defense against DoS attacks. Everything simplifies a bit when we assume these communications using non-private way as simple HTTPS-requests-responses, but I think we are sacrificing too much privacy on the way. > Once a path is found, the recipient would then communicate over > the wallet-to-wallet channel to pass over the fully-constructed > onion routing information. Sending that data back over the onion > routing network may not be necessary. Unfortunately this increases > the complexity of the payment side (wallet-to-wallet), but > meanwhile makes for less message passing in onion land, which could > make the problem easier to think about? Do you mind defining wallet-to-wallet channel a bit more? Which techniques could/should they use without leaking information? Yes, we would increase the total load for the nodes if they should handle these additional messages. But I think we can go with a simplified message-delivery-system where each hop costs like 1 satoshi. I call it simplified, because we are not using the a HTLC, but just rebalancing the unencumbered outputs of the commit transaction. As the sender of a message you can go to the first node and give him 30 satoshis for opening the onion object and passing the message to the next node as instructed in the onion object. It would pay the next node 29 satoshis, and so on. These would not be enforcable on the blockchain, so a dishonest node could just keep the 29 satoshis and not deliver anything at all. However, if you receive a message to relay it, it is a strong indication that there is a payment to follow up to that message. The general incentive is to relay these messages, as fees of payment are likely higher. Given that we can have sub-satoshi payments too, we might want to tune the cost-per-hop to make it substantially less than any fees you could get of the payment. If it remains a problem (and some people could just join the network and not relay anything just for the sake of it), we might either find a way to proof this behavior or even use HTLCs for these, even though that would probably be not practical and bloat commit transactions waay too much. - -- 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 iQIcBAEBCgAGBQJWZ/gwAAoJEAYZmwZ/PsbKv4MQAKxoeZ+G3ozifODlY7nhqYeE GQChU8DyDal8tAn1Bgb44s7SZMltSgpL9RR2G51/Cn0pygPMPUkT9OS5mRNMlEA1 s1JZ3annaxkJslUlFeF86Tw1MC8LhFYi/WbnJoCPElTmR1PljOtCmpUpjlrDMx7N YNyjD/zUR+N1ZMqZh0q5okoZegyOkgo0biT5RHrjALUEnK3qWh/PCwUHXYdN/l22 h0LaEi0ajTFhEPNygSFz3Z13KmwYvsmsHl9MydweLbKARx6wo7OPxOWbuNVqD7xF 4eGgkniQZgZM+8owYFifXn/XVGj65PLQaqCN0o/gmCKphqjgoPWtbcJtKg8NtShN 6AI54ZqAtqh4IxpOZRBm2OiFW5TTou/XICDrCS/mfCNtv0wYNANop9+WQ/KTfStx KnL986TDww5XkLws30Q9C6qFpBjwEgmTmGibvCM8z+HPe223kW0ElofLrWmvqyso Ncj+iKj91cJLbs3XuzZ6pMgBwhW0ERSRj4bUm6r/oApSRyxYNNLVchOFhU9eWJxu dhJul2ACFpcTql2zQOUhUe3PXD6M3cRpyLgeqRMNGNNs4+3eTnFdNiqWjK+QIIvZ uFWpUDcPh3TJSh7TBZCHSxtAIHpCUyPL8u/LV6oZ4PHSd5aLMMm5tq95ViDNzAvm ARTMgJtNA6q4CYlUflr3 =b/hD -----END PGP SIGNATURE-----