Re: Non-source routing (was "failures during the preparation phase")

Pedro- Thanks, I will look at ZeroPay. As for RPR, I think that it is
likely far less bandwidth efficient than either of your approaches. However
it would perform well in scenarios where connectors are moving a lot of
their liquidity at once (trading), because routes determined by it will be
about as up-to-date as possible. It's derived from an IP routing protocol
called AODV.

-Jehan

On Fri, Mar 25, 2016 at 11:08 PM, Evan Hubinger <evanjhub@gmail.com> wrote:

> I think the sort of landmark routing you describe could be very useful if
> the topology of the network was such that a large proportion of the
> available liquidity was concentrated in a single node, which seems likely,
> at least early on. The way you have described it, however, it seems more
> like an alternative pathfinding algorithm than an alternative routing
> system, since one could theoretically use this method to efficiently
> compute a route at the sender, and then you're using source routing, or
> efficiently compute a route at each step, and then you're using dynamic
> routing. Either way, I don't think this would require a protocol change,
> since it would just be a choice of algorithm on behalf of the
> sender/connector in question. I could be completely wrong and
> misinterpreting your proposal, however.
>
> On Fri, Mar 25, 2016 at 7:44 PM, Daniel Bateman <7daniel77@gmail.com>
> wrote:
>
>> Thank you Pedro!
>>
>> High hopes for this approach.
>> On Mar 25, 2016 7:30 PM, "Pedro Moreno Sanchez" <pmorenos@purdue.edu>
>> wrote:
>>
>>>  Thank you for your interest!
>>>
>>> Given the interest, I have uploaded the current draft of ZeroPay [1],
>>> the other system on which we are currently working. As I said in my
>>> previous email, it shows that it is possible to enforce strong privacy
>>> guarantees (as we did with PrivPay) in a distributed setting, where each
>>> node in the network only need to know its neighbors (e.g., its own credit
>>> links).
>>>
>>> On 3/25/16 6:07 PM, Jehan Tremback wrote:
>>>
>>> Do landmark nodes have a special role in the network? Must someone
>>> "appoint" a landmark node, or can any node step in and fill this role at
>>> any time?
>>>
>>> In principle any node in the network could play the role of landmark
>>> since a landmark is just an intermediate node in the path from the sender
>>> to the receiver. However, I believe that in practice, nodes with high
>>> liquidity are more likely to play the role of landmarks since many payments
>>> are routed through them. For example, banks would be the natural candidate
>>> to server as landmarks in a payment system. In Ripple, most nodes have
>>> links to a few highly connected nodes (Ripple gateways).
>>>
>>> Where is the "Universe Creator" located?
>>>
>>> In PrivPay, the universe creator is a functionality that is carried out
>>> at the server side. In a bit more detail, the universe creator is executed
>>> in a secure processor (e.g., the 4765 cryptographic co-processor by IBM
>>> [2]) installed in the server. This processor is considered secure in the
>>> sense that it is not possible to spy on the computations performed inside
>>> of it or read its (small) internal memory. There are other works that have
>>> successfully used such a trusted platform to solve privacy issues on other
>>> scenarios [3, 4].
>>>
>>> Am I correct in inferring that this is a system designed to be run on a
>>> centralized node that knows about the entire network topology?
>>>
>>> The complete credit network is stored on the server in an encrypted
>>> fashion. The key for such encryption is stored in the secure processor.
>>> Thus, the server does not have access to any information about the network
>>> (and thus it does not know the network topology) since it is not possible
>>> to extract the key from the secure processor.
>>>
>>> In such setting, it is still challenging to perform changes over the
>>> encrypted credit network to carry out the payments. The naive solution of
>>> decrypting the complete credit network within the secure processor's memory
>>> does not work because this memory is small. Another possibility would be to
>>> sequentially decrypt the necessary blocks from the encrypted credit
>>> network, perform the changes and encrypt them back. This, however, leaks
>>> information about the access pattern and this leak can be used by the
>>> untrusted server to figure out who is the receiver of a transaction or the
>>> transacted value. We solve this challenging problem in PrivPay by designing
>>> algorithms that obliviously access the encrypted data (i.e., hiding the
>>> access patterns).
>>>
>>> Btw, I have seen in a previous email in this mailing list that you are
>>> working on a payment routing protocol (Reactive Payment Routing). I think
>>> that it would be interesting to compare this approach with our ongoing work
>>> ZeroPay [1]. It might be worth it to see what we can extract from both
>>> approaches to handle pathfinding and privacy issues on ILP.
>>>
>>> -Pedro
>>>
>>> [1] Kate, A., Maffei, M., Malavolta, G., Moreno-Sanchez, P., ZeroPay: A
>>> Distributed Architecture for Enforcing Privacy in Credit Networks. Work in
>>> progress.
>>> http://crypsys.mmci.uni-saarland.de/projects/DecentralizedPrivPay/draft-paper.pdf
>>> [2] IBM Systems, "IBM Systems cryptographic hardware products,"
>>> http://www-03.ibm.com/security/cryptocards/
>>> [3] Backes, M., Kate, A., Maffei, M., Pecina, K., ObliviAd: Provably
>>> Secure and Practical Online Behavioral Advertising. In IEEE S&P 2012.
>>> http://sps.cs.uni-saarland.de/publications/obliviad.pdf
>>> [4] Bajaj, S., Sion, R., TrustedDB: A Trusted Hardware Based Outsourced
>>> Database Engine. In PVLDB 2011.
>>>
>>>
>>> -Jehan
>>>
>>> On Fri, Mar 25, 2016 at 2:36 PM, Daniel Bateman <7daniel77@gmail.com>
>>> wrote:
>>>
>>>> Interesting!
>>>>
>>>> Can Interledger function with a system like PrivPay?
>>>> On Mar 25, 2016 2:32 PM, "Pedro Moreno Sanchez" <pmorenos@purdue.edu>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> my name is Pedro Moreno-Sanchez and I am a PhD student at the computer
>>>>> science department at Purdue. My current research focuses on security and
>>>>> privacy issues on credit networks. Moreover, I will be doing an internship
>>>>> at Ripple this summer. Thus, I hope I can use this opportunity to meet some
>>>>> of you there and discuss the interesting things that are going on in this
>>>>> group.
>>>>>
>>>>> I would like to bring to your attention a (non-source) routing
>>>>> approach called landmark routing [1]. In a nutshell, this approach
>>>>> calculates a path between a sender and a receiver through an intermediary
>>>>> node called landmark. The idea behind this approach is to calculate the
>>>>> shortest path (i.e., Breadth-First Search) from the landmark to every other
>>>>> node and vice versa, from every node to the landmark. Then, a payment path
>>>>> from sender to receiver can be reconstructed as sender -->other nodes -->
>>>>> landmark --> other nodes ---> receiver. Vismanath et al.[2] have shown that
>>>>> landmark routing performs much faster than other routing approaches (e.g.,
>>>>> using max-flow) in credit networks.
>>>>>
>>>>> Given the similarities between a credit network and the ILP settings,
>>>>> it might be worth it discussing this approach here. Moreover, as part of my
>>>>> research, I have studied whether it is possible to use landmark routing to
>>>>> build a credit network with privacy preserving payments. This is
>>>>> challenging not only because of possible privacy leaks while calculating
>>>>> payment paths but also due to privacy leaks during the calculation of the
>>>>> available credit in a path.
>>>>>
>>>>> To overcome these challenges, we designed a system called PrivPay [3],
>>>>> a credit network system that uses a privacy-enhanced version of landmark
>>>>> routing to perform privacy preserving payments. More recently, we have
>>>>> designed a privacy-preserving credit network system with which we show that
>>>>> it is possible to enforce strong privacy guarantees as we did with PrivPay
>>>>> but in a distributed setting, where each node in the network only knows its
>>>>> neighbors (e.g., its own credit links). Although this last work is not
>>>>> published yet, I would be glad to share and discuss it with you if you are
>>>>> interested.
>>>>>
>>>>> I would be interested on discussing my experiences during my research
>>>>> regarding not only routing mechanisms on credit networks, but also privacy
>>>>> preserving payments. I believe that privacy is an interesting and important
>>>>> aspect that might be worth considering on the ongoing discussions about ILP.
>>>>>
>>>>> --
>>>>> [1] P. F. Tsuchiya, “The Landmark Hierarchy: A New Hierarchy for
>>>>> Routing in Very Large Networks,” SIGCOMM Comput. Commun. Rev., vol.
>>>>> 18, no. 4, pp. 35–42, Aug. 1988.
>>>>> [2] B. Viswanath, M. Mondal, K. P. Gummadi, A. Mislove, and A. Post,
>>>>> “Canal: Scaling Social Network-based Sybil Tolerance Schemes,” in EuroSys
>>>>> ’12, 2012, pp. 309–322.
>>>>> [3] Moreno-Sanchez, P., Kate, A., Maffei, M., and Pecina, K. Privacy
>>>>> preserving payments in credit networks: Enabling trust with privacy in
>>>>> online marketplaces. In NDSS(2015).
>>>>> http://www.internetsociety.org/doc/privacy-preserving-payments-credit-networks-enabling-trust-privacy-online-marketplaces
>>>>>
>>>>
>>>
>>>
>
>
> --
> “The true logic of this world is in the calculus of probabilities.” –
> James Clerk Maxwell
>